From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Oct 1 09:12: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 JAA08621 for ; Sun, 1 Oct 2000 09:12:45 -0400 (EDT) Received: from standards (47.234.32.16:4365) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A817@standards.nortelnetworks.com>; 1 Oct 2000 8:56:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8509 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 1 Oct 2000 08:56:09 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A811@standards.nortelnetworks.com>; 1 Oct 2000 8:46:09 -0400 Received: from fw.hbwhptt.net.cn. ([202.103.0.161]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id IAA22333 for ; Sun, 1 Oct 2000 08:00:21 -0500 (CDT) Received: from 202.103.0.161 by fw.hbwhptt.net.cn. (SMI-8.6/SMI-SVR4) id MAA24586; Sun, 1 Oct 2000 12:13:56 -0800 Received: from cabnewstv3@rocketmail.com by cabnewstv3@rocketmail.com (8.8.5/8.6.5) with SMTP id GAA05196 for ; Sun, 01 Oct 2000 03:56:35 -0600 (EST) Message-ID: <> Date: Sun, 1 Oct 2000 03:56:35 EST Reply-To: cabnewstv3@ROCKETMAIL.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: cabnewstv3@ROCKETMAIL.COM Subject: [MOBILE-IP] CABLE TV X-To: cabnewstv3@rocketmai.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM NOTE: THIS IS AN ADVERTISEMENT FOR LEGAL TV DE-SCRAMBLER. IF YOU HAVE NO INTEREST IN THIS INFORMATION PLEASE CLICK DELETE NOW. THANK YOU-- LEGAL CABLE TV DE-SCRAMBLER Want to watch Sporting Events?--Movies?--Pay-Per-View?? You can assemble from electronic store parts for about $12.00. We Send You: E-Z To follow Assembly Instructions. E-Z To read Original Drawings. Electronic parts lists. PLUS SOMETHING NEW YOU MUST HAVE! Something you can't do without. THE UP-TO-DATE REPORT: USING A DESCRAMBLER LEGALLY Warning: You should not build a TV Descrambler without reading this report first. Frequently Asked Questions--CABLE TV DESCRAMBLER Q: Will the descrambler work on Fiber, TCI, Jarrod A: The answer is YES. Q: Do I need a converter box? A: This plan works with or without a converter box. Specific instructions are included in the plans for each! Q: Can the cable company detect that I have the descrambler? A: No, the signal descrambles right at the box and does not move back through the line! Q: Do I have to alter my existing cable system, television or VCR? A: The answer is no! Q: Does this work with my remote control? A: The answer is yes. The descrambler is manually controlled--but very easy to use! Q: Can you email me the plans? A: No the program comes with an easy to follow picture guide. Q: Does this work everywhere across the country? A: Yes, every where in the USA plus England, Brazil, Canada and other countries! Q: Is this deal guaranteed? A: Yes, if you are unhappy for any reason we will refund your money. ORDER INFORMATION ACT WITHIN THE NEXT 7 DAYS AND RECEIVE TWO FREE BONUS!! THE CABLE MANUAL! This manual contains hard to find information your cable company does not want you to know. Also receive The RADAR JAMMER PLANS! Never get another speeding ticket. Build you own radar jammer, this unit will jam police radar so they can't get a reading on your vechicle. Radar jammers are legal in 48 states. It is simple to build. The FREE BONUSES ALONE ARE WORTH ACTING NOW! THE CABLE DESCRAMBLER KIT COMES WITH A THIRTY DAY MONEY BACK GUARANTEE! IF YOUR NOT COMPLETELY SATISFIED, SEND THE CABLE DESCRAMBLER KIT BACK AND YOU KEEP THE BONUSES FOR FREE. YOU HAVE NOTHING TO LOSE ACT NOW AND SAVE!! SIMPLY SEND $12.95, THAT'S ONLY $12.95 BUT YOU MUST ORDER WITHIN 7 DAYS FOR THIS SPECIAL PRICE!!! SEND $12.95 CHECK OR, MONEY ORDER, OR CREDIT CARD INFORMATION TO: QUALITY RESOURCES 5399 EAST HWY C30-A #242 SEAGROVE BEACH, FL 32459 FOR CREDIT CARD ORDERS FILL OUT THIS FORM AND MAIL IN, ATTENTION QUALITY RESOURCES, here is my credit card information for the amount of $12.95 for the cable descrambler kit. ACCOUNT NUMBER____________________________________ EXP. DATE____________________ NAME_____________________________________________ BILLING ADDRESS__________________________________________ CITY/STATE/ZIP_____________________________________ HOME PHONE__________________________________ THIS INFORMATION IS SOLD FOR EDUCATIONAL PURPOSES ONLY! This mailing is done by an independent marketing co. We apologize if this message has reached you in error. Save the Planet, Save the Trees! Advertise via E mail. No wasted paper! Delete with one simple keystroke! Less refuse in our Dumps! This is the new way of new millennium! If you would like to be removed cartor12@dcemail.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Oct 1 22:04: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 WAA15652 for ; Sun, 1 Oct 2000 22:04:58 -0400 (EDT) Received: from standards (47.234.32.16:3509) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A955@standards.nortelnetworks.com>; 1 Oct 2000 21:48:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8957 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 1 Oct 2000 21:48:44 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A954@standards.nortelnetworks.com>; 1 Oct 2000 21:38:43 -0400 Received: from signal (ip105.houston13.tx.pub-ip.psi.net [38.27.213.105]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id UAA25804 for ; Sun, 1 Oct 2000 20:52:57 -0500 (CDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <499.283843.122433@signal> Date: Sun, 1 Oct 2000 21:48:44 -0400 Reply-To: realinc@PROPS.NET Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: realinc@PROPS.NET Subject: Re: [MOBILE-IP] Six Figure Income Now X-To: mobile-ip@smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit You were recently referred as someone who had a serious interest in earning a Six Figure Income, but did not want to be involved in MLM or a Franchise. If that is still the case, and if you have reached the point in your life where you are ready for Financial Freedom and a Real Opportunity to Retire in 2-4 years, calling the number below is your first step. This is a serious business looking only for those that want to make a MINIMUM of $10,000 per month and to truly be in a position to help others at the same time. **24 Hour Recorded Message: 1-800-320-9895 Ext. 5433** Your background, age and debt level are not important. Just a strong desire for financial independence. "If we all did the things we are capable of doing, we would literally astound ourselves." Thomas A. Edison To be removed respond at notnow1000@yahoo.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 2 03:06: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 DAA03078 for ; Mon, 2 Oct 2000 03:06:35 -0400 (EDT) Received: from standards (47.234.32.16:1466) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9AACE@standards.nortelnetworks.com>; Mon, 2 Oct 2000 2:50:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9478 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 2 Oct 2000 02:50:04 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9AACC@standards.nortelnetworks.com>; Mon, 2 Oct 2000 2:40:03 -0400 Received: from zuptsvr2.Com4.com.br ([200.210.15.67]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id BAA27191 for ; Mon, 2 Oct 2000 01:54:21 -0500 (CDT) Received: from dns [209.206.56.107] by zuptsvr2.Com4.com.br (SMTPD32-4.06) id A8A42BF00F0; Mon, 02 Oct 2000 02:53:24 EST Message-ID: <200010020654.BAA27191@hosaka.smallworks.com> Date: Sat, 2 Oct 0100 02:55:02 EST Reply-To: Opt-In9258059@ATT.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Opt-In9258059@ATT.COM Subject: [MOBILE-IP] How you can make $100 - $500 an hour doing something FUN X-To: opt_in45@anmail.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM From: Michelle Smith - publisher of the "Money Making Opportunities" Newsletter Sunday, 9 p.m. Hello, If you're interested in earning $100 - $500 an hour doing something FUN, Then I want to share something with you... Imagine you come home from a hard day's work (exhausted..) You immediately go straight to bed. You get undressed, lay down, turn off the lights, and snuggle up face-down on the pillow. A few moments later, you feel uncomfortable and stressed out so you lie on your back. When you look up at the ceiling, it's as if the ceiling has been removed! You see exactly what you would see if outside stargazing! A stunning, accurate 3-dimensional re-creation of the starry night sky, including constellations such as the Big Dipper, Pegasus and the Milky Way galaxy, ...and even shooting stars! You can't see it during the day. The ceiling looks normal. But at night, when the lights are off, you see what looks like the sky outside! It's so relaxing and romantic. And educational! And talk about stress-relief! The moment you look at it, it'll melt your tension away faster than a great massage! Now how many people do you think would LOVE seeing this when they look up in their beds at night? "It's like you're sleeping under the stars!" Ok, I know you want to know How You Make Money. Here's how. You can put that awesome "convertible ceiling" in ANYONE'S bedroom with a product cost to you of.. Guess how much.. Only ONE to TWO Dollars! You offer this masterpiece for $100 - $500! Talk about *nice* profits! And it only takes you an hour or two! Here's an important point: These profits are similar to the profits of selling Information: the material costs next to nothing, but the customer really VALUES the END RESULT. So the market value is more (a LOT more). "Who'd want this?" Anyone with a bedroom ceiling (or any ceiling), as well as homes, hotels, etc. Who do you know that has a bedroom ceiling? Whew! The official money-making opportunity of the Millenium! (Well... we think it should be!) |;-) Anyway, I know you want more information to make a decision, so ... To receive more FREE information on How To Make $100 - $500 An Hour, Simply Click On The Email Link Below and Send Back The Following: Mailto:stargazing41@newmail.net Name: E-Mail: Phone: Street: City: State: ZIP or Postal Code: Country (available INTERNATIONALLY): Mailto:stargazing41@newmail.net And you'll be sent the full details on how to make $100 - $500 an hour, as well as pictures of these murals so you can see for yourself how breathtaking they are! Best regards, Michelle Smith P.S. We'll also send you a free Opportunity E-zine with more interesting Money-Making Opportunities like this one, and important info. for the home-based entrepreneur! P.P.S. Also, even though 99% of people don't know about this opportunity, that won't be the case forever, so hurry up and reply to make sure you get to lock down YOUR city! To unsubscribe mailto:unsubscribe-930@newmail.net From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 2 11:45: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 LAA09837 for ; Mon, 2 Oct 2000 11:45:39 -0400 (EDT) Received: from standards (47.234.32.16:1214) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9ACC6@standards.nortelnetworks.com>; Mon, 2 Oct 2000 11:28:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10100 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 2 Oct 2000 11:28:02 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9ACA3@standards.nortelnetworks.com>; Mon, 2 Oct 2000 11:18:02 -0400 Received: from 7min.com ([210.124.122.56]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id KAA29378 for ; Mon, 2 Oct 2000 10:32:17 -0500 (CDT) Received: from sdn-ar-002tnknoxP277.dialsprint.net_[168.191.249.207] [168.191.249.207] by 7min.com (SMTPD32-6.00) id A6B48D002A; Tue, 03 Oct 2000 00:16:04 +0900 Received: from 168.191.249.207 by sdn-ar-002tnknoxP277.dialsprint.net with ESMTP; Mon, 02 Oct 2000 11:23:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <000031601c11$000003ff$0000582b@168.191.249.207> Date: Mon, 2 Oct 2000 11:23:05 -0400 Reply-To: choes@EARTHLINK.NET Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: choes@EARTHLINK.NET Subject: [MOBILE-IP] Fire The Creep You Call Your Boss!! 22571 X-To: Undisclosed.Recipients@hosaka.smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit
FOLLOW ME TO FINANCIAL FREEDOM!!

I Am looking for people with good work ethic and extrordinary desire
to earn at least $10,000 per month working from home!

NO SPECIAL SKILLS OR EXPERIENCE REQUIRED We will give you all the
training and personal support you will need to ensure your success!

This LEGITIMATE HOME-BASED INCOME OPPORTUNITY can put you back in
control of your time,your finances,and your life!

If you've tried other opportunities in the past that have failed to
live up their promises,

THIS IS DIFFERENT THEN ANYTHING ELSE YOU'VE SEEN!

THIS IS NOT A GET RICH QUICK SCHEME!

YOUR FINANCIAL PAST DOES NOT HAVE TO BE YOUR FINANCIAL FUTURE!

CALL ONLY IF YOU ARE SERIOUS!

1-800-345-9708

DONT GO TO SLEEP WITHOUT LISTENING TO THIS!

"ALL our dreams can come true- if we have the courage to persue them"
-Walt Disney

Please Leave Your Name And Number And Best Time To Call

DO NOT RESPOND BY EMAIL

------------------------------------------------------------------------
This message is sent in compliance of the new email bill section
301.PerSection
301, Paragraph (a)(2)(C) of S. 1618. We will comply with all removal
requests.Just Put Remove
mailto:bagboy@burmeses.net ------------------------------------------------------------------------ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 2 17:00: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 RAA14056 for ; Mon, 2 Oct 2000 17:00:01 -0400 (EDT) Received: from standards (47.234.32.16:2875) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9AEAB@standards.nortelnetworks.com>; Mon, 2 Oct 2000 16:43:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10756 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 2 Oct 2000 16:43:41 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9AEA6@standards.nortelnetworks.com>; Mon, 2 Oct 2000 16:33:40 -0400 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Mon Oct 2 16:46:45 EDT 2000 Received: from valjean.dnrc.bell-labs.com (IDENT:root@valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA28118 for ; Mon, 2 Oct 2000 16:46:45 -0400 (EDT) Received: (from salga@localhost) by valjean.dnrc.bell-labs.com (8.9.3/8.8.7) id QAA24571 for MOBILE-IP@standards.nortelnetworks.com; Mon, 2 Oct 2000 16:46:45 -0400 Mail-Followup-To: MOBILE-IP@standards.nortelnetworks.com References: <39D27A27.E7029F87@comet.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Organization: Bell Laboratories Message-ID: <20001002164645.N19948@bell-labs.com> Date: Mon, 2 Oct 2000 16:46:45 -0400 Reply-To: Luca Salgarelli Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Luca Salgarelli Subject: Re: [MOBILE-IP] Fast Handoff v4 archives available To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <39D27A27.E7029F87@comet.columbia.edu>; from campbell@comet.columbia.edu on Wed, Sep 27, 2000 at 03:52:23PM -0700 Basavaraj, Andrew, I would like to add some comments to what Andrew wrote. > Regards the process: I thought the idea was to come up with a set of > requirements, then a strawman proposal that sort consensus and met the > requirements? > > It looks like the starting point was too narrow? > > It looks like the output from the design team resulted in deltas to > existing IDs? (Why are these two IDs technically superior to others?). > > In addition, weeding out some IDs because they didn't support tunneling > (e.g., Hawaii) or MIP messaging (e.g., CIP), etc. was a bad call in a > process that should have been open and inclusive and now looks like on > the surface to have preselected two IDs (i.e., fast handoff/ proactive > IDs) that have not been proven "better" than others. I completely agree with Andrew. Several weeks ago I wrote a message to the WG asking clarifications about this process, but those questions were left unanswered. I too thought that the goal of this sub-WG (?) was to come up with a set of requirements. While I do not question the technical soundness of the proposals (not requirements) that this sub-WG has defined, I still do not understand the process through which the goals for the sub-WG were set, and how the sub-WG was formed. I also do not understand how the WG can benefit in the long run from this seemingly closed process where no real discussion has taken place on the technical merits (or lack of thereof, for what matters) of the IDs that were left out. Would someone please comment on this? Thanks Luca From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 2 17:09: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 RAA14189 for ; Mon, 2 Oct 2000 17:09:02 -0400 (EDT) Received: from standards (47.234.32.16:2875) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9AEF9@standards.nortelnetworks.com>; Mon, 2 Oct 2000 16:52:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10863 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 2 Oct 2000 16:52:34 -0400 Received: from qhars002.nortel.com (47.101.112.102:37911) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9AEF8@standards.nortelnetworks.com>; Mon, 2 Oct 2000 16:52:34 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Mon, 2 Oct 2000 22:06:43 +0100 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Mon, 2 Oct 2000 16:06:26 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 2 Oct 2000 16:06:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02CB4.8C5CA0B0" Message-ID: <40DC7CF03BDDD3118F3D0000F806EEEC4F33AA@zrchb199.us.nortel.com> Date: Mon, 2 Oct 2000 16:05:52 -0500 Reply-To: Haseeb Akhtar Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Haseeb Akhtar Subject: Re: [MOBILE-IP] Fast Handoff v4 archives available X-To: Luca Salgarelli 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_01C02CB4.8C5CA0B0 Content-Type: text/plain Hello folks, Ditto. The requirements should have come first before the solution! Regards, Haseeb > -----Original Message----- > From: Luca Salgarelli [SMTP:lsalgarelli@BELL-LABS.COM] > Sent: Monday, October 02, 2000 3:47 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Fast Handoff v4 archives available > > Basavaraj, Andrew, > > I would like to add some comments to what Andrew wrote. > > > Regards the process: I thought the idea was to come up with a set of > > requirements, then a strawman proposal that sort consensus and met the > > requirements? > > > > It looks like the starting point was too narrow? > > > > It looks like the output from the design team resulted in deltas to > > existing IDs? (Why are these two IDs technically superior to others?). > > > > In addition, weeding out some IDs because they didn't support tunneling > > (e.g., Hawaii) or MIP messaging (e.g., CIP), etc. was a bad call in a > > process that should have been open and inclusive and now looks like on > > the surface to have preselected two IDs (i.e., fast handoff/ proactive > > IDs) that have not been proven "better" than others. > > I completely agree with Andrew. Several weeks ago I wrote a message to the > WG asking clarifications about this process, but those questions were left > unanswered. I too thought that the goal of this sub-WG (?) was to come up > with a set of requirements. While I do not question the technical > soundness > of the proposals (not requirements) that this sub-WG has defined, I still > do not understand the process through which the goals for the sub-WG were > set, and how the sub-WG was formed. > > I also do not understand how the WG can benefit in the long run from this > seemingly closed process where no real discussion has taken place on the > technical merits (or lack of thereof, for what matters) of the IDs that > were left out. > > Would someone please comment on this? > > Thanks > Luca ------_=_NextPart_001_01C02CB4.8C5CA0B0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] Fast Handoff v4 archives available

Hello folks,

Ditto. The = requirements should have come first before the solution!

Regards,

Haseeb

    -----Original Message-----
    From:   Luca Salgarelli = [SMTP:lsalgarelli@BELL-LABS.COM]
    Sent:   Monday, October 02, 2000 3:47 PM
    To:     MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: [MOBILE-IP] Fast Handoff v4 = archives available

    Basavaraj, Andrew,

    I would like to add some comments to = what Andrew wrote.

    > Regards the process: I thought = the idea was to come up with a set of
    > requirements, then a strawman = proposal that sort consensus and met the
    > requirements?
    >
    > It looks like the starting point = was too narrow?
    >
    > It looks like the output from = the design team resulted in deltas to
    > existing IDs? (Why are these two = IDs technically superior to others?).
    >
    > In addition, weeding out some = IDs because they didn't support tunneling
    > (e.g., Hawaii) or MIP messaging = (e.g., CIP), etc.  was a bad call in a
    > process that should have been = open and inclusive and now looks like on
    > the surface to have preselected = two IDs (i.e., fast handoff/ proactive
    > IDs) that have not been proven = "better" than others.

    I completely agree with Andrew. = Several weeks ago I wrote a message to the
    WG asking clarifications about this = process, but those questions were left
    unanswered. I too thought that the = goal of this sub-WG (?) was to come up
    with a set of requirements. While I = do not question the technical soundness
    of the proposals (not requirements) = that this sub-WG has defined, I still
    do not understand the process through = which the goals for the sub-WG were
    set, and how the sub-WG was = formed.

    I also do not understand how the WG = can benefit in the long run from this
    seemingly closed process where no = real discussion has taken place on the
    technical merits (or lack of thereof, = for what matters) of the IDs that
    were left out.

    Would someone please comment on = this?

    Thanks
    Luca

------_=_NextPart_001_01C02CB4.8C5CA0B0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 2 18:15: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 SAA14871 for ; Mon, 2 Oct 2000 18:15:29 -0400 (EDT) Received: from standards (47.234.32.16:4602) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9AFAD@standards.nortelnetworks.com>; Mon, 2 Oct 2000 17:59:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11108 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 2 Oct 2000 17:59:10 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9AFAC@standards.nortelnetworks.com>; Mon, 2 Oct 2000 17:59:09 -0400 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA02552; Mon, 2 Oct 2000 16:13:28 -0600 (MDT) 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 PAA10999; Mon, 2 Oct 2000 15:13:27 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA24736; Mon, 2 Oct 2000 15:13:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 2 Oct 2000 15:11:17 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Fast Handoff v4 archives available X-To: Haseeb Akhtar To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <40DC7CF03BDDD3118F3D0000F806EEEC4F33AA@zrchb199.us.nortel.com> > > > > I completely agree with Andrew. Several weeks ago I wrote a message to the > > WG asking clarifications about this process, but those questions were left > > unanswered. I too thought that the goal of this sub-WG (?) was to come up > > with a set of requirements. hmmm... this must have come up when I wasn't there... However, both documents do list the problem to be solved. If you believe that you have a set of requirements that haven't been solved, then by all means, bring them up. Furthermore, if the WG wants to create an I-D with requirements, then I would be most interested as well. > > While I do not question the technical > > soundness > > of the proposals (not requirements) that this sub-WG has defined, I still > > do not understand the process through which the goals for the sub-WG were > > set, and how the sub-WG was formed. As discussed at the IETF, people that had contributions got together with the intention of reducing the number of I-Ds to one. I believe that the chairs decided that people with I-Ds were to work together. I suppose that they figured that if you didn't have an I-D written up in this space, then you probably didn't care to work on consolidating the I-Ds. > > > > I also do not understand how the WG can benefit in the long run from this > > seemingly closed process where no real discussion has taken place on the > > technical merits (or lack of thereof, for what matters) of the IDs that > > were left out. Which I-Ds? I was quite certain that we took all of them into account. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 2 18:33: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 SAA15060 for ; Mon, 2 Oct 2000 18:32:59 -0400 (EDT) Received: from standards (47.234.32.16:4602) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9AFF9@standards.nortelnetworks.com>; Mon, 2 Oct 2000 18:16:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11205 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 2 Oct 2000 18:16:45 -0400 Received: from qhars002.nortel.com (47.101.112.102:39546) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9AFF8@standards.nortelnetworks.com>; Mon, 2 Oct 2000 18:16:44 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Mon, 2 Oct 2000 23:30:52 +0100 Received: from zrchs148 by smtprch1.nortel.com; Mon, 2 Oct 2000 17:30:34 -0500 Received: from zrchb200.us.nortel.com (actually zrchb200) by zrchs148; Mon, 2 Oct 2000 17:22:40 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 2 Oct 2000 17:30:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02CC0.5AA994E0" Message-ID: <9A9367D1556AD21182C40000F80930AB025E5496@crchy28b.us.nortel.com> Date: Mon, 2 Oct 2000 17:30:23 -0500 Reply-To: Mohamed Khalil Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mohamed Khalil Subject: Re: [MOBILE-IP] Fast Handoff v4 archives available X-To: Haseeb Akhtar To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM ------_=_NextPart_001_01C02CC0.5AA994E0 Content-type: text/plain; charset="iso-8859-1" Hello folks, I agree with all completely. As a participant of the handoff meetings at the last IETF I was expecting to follow the engineering approach (Since we are all belong to the Internet Engineering Task Force) of coming up with a set of requirements for IPv4 then we propose different solutions which satisfy those requirements. Unfortunately, this never happened. MK -----Original Message----- From: Akhtar, Haseeb [RICH1:IP30-M:EXCH] Sent: Monday, October 02, 2000 4:06 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Fast Handoff v4 archives available Hello folks, Ditto. The requirements should have come first before the solution! Regards, Haseeb -----Original Message----- From: Luca Salgarelli [SMTP:lsalgarelli@BELL-LABS.COM] Sent: Monday, October 02, 2000 3:47 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Fast Handoff v4 archives available Basavaraj, Andrew, I would like to add some comments to what Andrew wrote. > Regards the process: I thought the idea was to come up with a set of > requirements, then a strawman proposal that sort consensus and met the > requirements? > > It looks like the starting point was too narrow? > > It looks like the output from the design team resulted in deltas to > existing IDs? (Why are these two IDs technically superior to others?). > > In addition, weeding out some IDs because they didn't support tunneling > (e.g., Hawaii) or MIP messaging (e.g., CIP), etc. was a bad call in a > process that should have been open and inclusive and now looks like on > the surface to have preselected two IDs (i.e., fast handoff/ proactive > IDs) that have not been proven "better" than others. I completely agree with Andrew. Several weeks ago I wrote a message to the WG asking clarifications about this process, but those questions were left unanswered. I too thought that the goal of this sub-WG (?) was to come up with a set of requirements. While I do not question the technical soundness of the proposals (not requirements) that this sub-WG has defined, I still do not understand the process through which the goals for the sub-WG were set, and how the sub-WG was formed. I also do not understand how the WG can benefit in the long run from this seemingly closed process where no real discussion has taken place on the technical merits (or lack of thereof, for what matters) of the IDs that were left out. Would someone please comment on this? Thanks Luca ------_=_NextPart_001_01C02CC0.5AA994E0 Content-type: text/html; charset="iso-8859-1" RE: [MOBILE-IP] Fast Handoff v4 archives available

Hello folks,

I agree with all completely. As a participant of the handoff meetings at the last IETF I was expecting to follow the engineering approach (Since we are all belong to the Internet Engineering Task Force) of coming up with a set of requirements for IPv4   then we propose different solutions which satisfy those requirements. Unfortunately, this never happened.

MK

-----Original Message-----
From: Akhtar, Haseeb [RICH1:IP30-M:EXCH]
Sent: Monday, October 02, 2000 4:06 PM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] Fast Handoff v4 archives available

Hello folks,

Ditto. The requirements should have come first before the solution!

Regards,

Haseeb

    -----Original Message-----
    From:   Luca Salgarelli [SMTP:lsalgarelli@BELL-LABS.COM]
    Sent:   Monday, October 02, 2000 3:47 PM
    To:     MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
    Subject:        Re: [MOBILE-IP] Fast Handoff v4 archives available

    Basavaraj, Andrew,

    I would like to add some comments to what Andrew wrote.

    > Regards the process: I thought the idea was to come up with a set of
    > requirements, then a strawman proposal that sort consensus and met the
    > requirements?
    >
    > It looks like the starting point was too narrow?
    >
    > It looks like the output from the design team resulted in deltas to
    > existing IDs? (Why are these two IDs technically superior to others?).
    >
    > In addition, weeding out some IDs because they didn't support tunneling
    > (e.g., Hawaii) or MIP messaging (e.g., CIP), etc.  was a bad call in a
    > process that should have been open and inclusive and now looks like on
    > the surface to have preselected two IDs (i.e., fast handoff/ proactive
    > IDs) that have not been proven "better" than others.

    I completely agree with Andrew. Several weeks ago I wrote a message to the
    WG asking clarifications about this process, but those questions were left
    unanswered. I too thought that the goal of this sub-WG (?) was to come up
    with a set of requirements. While I do not question the technical soundness
    of the proposals (not requirements) that this sub-WG has defined, I still
    do not understand the process through which the goals for the sub-WG were
    set, and how the sub-WG was formed.

    I also do not understand how the WG can benefit in the long run from this
    seemingly closed process where no real discussion has taken place on the
    technical merits (or lack of thereof, for what matters) of the IDs that
    were left out.

    Would someone please comment on this?

    Thanks
    Luca

------_=_NextPart_001_01C02CC0.5AA994E0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 03:38: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 DAA04131 for ; Tue, 3 Oct 2000 03:38:15 -0400 (EDT) Received: from standards (47.234.32.16:3849) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B17D@standards.nortelnetworks.com>; Tue, 3 Oct 2000 3:21:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11735 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 03:21:58 -0400 Received: from mailserv.intranet.GR by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B17C@standards.nortelnetworks.com>; Tue, 3 Oct 2000 3:21:58 -0400 Received: from patreas.patra.intranet.gr by mailserv.intranet.GR with ESMTP (8.8.8/ICM-mailhub-1.0) id KAA25355; Tue, 3 Oct 2000 10:33:30 +0300 (EET DST) Received: from intranet.gr (patdpd17 [146.124.171.40]) by patreas.patra.intranet.gr (8.9.1b+Sun/8.9.0) with ESMTP id KAA23107 for ; Tue, 3 Oct 2000 10:46:24 +0300 (EET DST) X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: 7bit Message-ID: <39D98BB3.A2021FEE@intranet.gr> Date: Tue, 3 Oct 2000 10:33:07 +0300 Reply-To: Christos Chrisanthakopoulos Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Christos Chrisanthakopoulos Subject: [MOBILE-IP] MIP implementation !!! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Good morning folks ! Can someone please tell me whats going on with the Binghamton UNIs URL for the Linux implementation on Mobile IP? Its been for ages that Im trying to download the files but it seems that the URL doesn't work anymore. Does anyone know if they have any updated versions of the implementation which runs on 2.2.x Kernells? Regards, Christos -- Christos Chrisanthakopoulos INTRACOM S.A. Development Programmes Department Panepistimiou 254 26443 Patras GREECE Tel: (+30 61) 465153 (direct) E-mail: xchr@intranet.gr URL: www.intracom.gr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 07:01: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 HAA05625 for ; Tue, 3 Oct 2000 07:01:16 -0400 (EDT) Received: from standards (47.234.32.16:1848) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B257@standards.nortelnetworks.com>; Tue, 3 Oct 2000 6:44:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12004 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 06:44:47 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B24A@standards.nortelnetworks.com>; Tue, 3 Oct 2000 6:34:46 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05305; Tue, 3 Oct 2000 06:49:09 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200010031049.GAA05305@ietf.org> Date: Tue, 3 Oct 2000 06:49:09 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-gnaie-01.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 : Generalized NAI Extension (GNAIE) Author(s) : M. Khalil, E. Qaddoura, H. Akhtar, P. Calhoun Filename : draft-ietf-mobileip-gnaie-01.txt Pages : 7 Date : 02-Oct-00 The Mobile IP Extensions Rationalization (MIER) specification defines a new extension header format, that is intended to extend the Mobile IP extension address space. This document defines the Generalized Network Access Identifier (NAI) extension, which SHOULD be used by any Mobile IP extension specifying an extension containing an NAI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-gnaie-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-gnaie-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-gnaie-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001002120522.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-gnaie-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-gnaie-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001002120522.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 07:12: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 HAA05858 for ; Tue, 3 Oct 2000 07:12:33 -0400 (EDT) Received: from standards (47.234.32.16:1848) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B2B3@standards.nortelnetworks.com>; Tue, 3 Oct 2000 6:54:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12140 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 06:54:59 -0400 Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B2B2@standards.nortelnetworks.com>; Tue, 3 Oct 2000 6:54:59 -0400 Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id HAA19029 for ; Tue, 3 Oct 2000 07:09:18 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id HAA19008 for ; Tue, 3 Oct 2000 07:09:15 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Oct 2000 12:09:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C048772E7@en0060exch001u.uk.lucent.com> Date: Tue, 3 Oct 2000 12:09:12 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: [MOBILE-IP] Are requirements required? X-To: Mohamed Khalil To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I think I could start writing the requirements right now: 1) the solution MUST NOT suck (for a definition of "suck", consider the scalability of host based routing) 2) the solution MUST be based on tunnels, since this is the way mobile IPv4 works 3) the solution MUST NOT be based on host routing (missing this, requirement 1) would be violated) 4) the solution MUST include security mechanisms that work fine and fast. 5) the solution MUST be fast/low interruption. 6) During handoff it MUST be possible to transfer some info to the new FA. 7) queries to AAA servers MUST be minimized ... do we have to read this from an ID? Or, wouldn't it be faster to build on what some colleagues have written in some documents, and try to improve them if possible? That is send comments to the list/authors??? $ 2/100 alessio > ---------- > From: Mohamed Khalil[SMTP:mkhalil@NORTELNETWORKS.COM] > Reply To: Mohamed Khalil > Sent: 02 October 2000 23:30 > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Fast Handoff v4 archives available > > Hello folks, > > I agree with all completely. As a participant of the handoff meetings at > the last IETF I was expecting to follow the engineering approach (Since we > are all belong to the Internet Engineering Task Force) of coming up with a > set of requirements for IPv4 then we propose different solutions which > satisfy those requirements. Unfortunately, this never happened. > > MK > > -----Original Message----- > From: Akhtar, Haseeb [RICH1:IP30-M:EXCH] > Sent: Monday, October 02, 2000 4:06 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Fast Handoff v4 archives available > > > > Hello folks, > > Ditto. The requirements should have come first before the solution! > > Regards, > > Haseeb > > -----Original Message----- > From: Luca Salgarelli [SMTP:lsalgarelli@BELL-LABS.COM] > Sent: Monday, October 02, 2000 3:47 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Fast Handoff v4 archives available > > Basavaraj, Andrew, > > I would like to add some comments to what Andrew wrote. > > > Regards the process: I thought the idea was to come up > with a set of > > requirements, then a strawman proposal that sort consensus and met > the > > requirements? > > > > It looks like the starting point was too narrow? > > > > It looks like the output from the design team resulted in deltas > to > > existing IDs? (Why are these two IDs technically superior to > others?). > > > > In addition, weeding out some IDs because they didn't support > tunneling > > (e.g., Hawaii) or MIP messaging (e.g., CIP), etc. was a bad call > in a > > process that should have been open and inclusive and now looks > like on > > the surface to have preselected two IDs (i.e., fast handoff/ > proactive > > IDs) that have not been proven "better" than others. > > I completely agree with Andrew. Several weeks ago I wrote a > message to the > WG asking clarifications about this process, but those questions > were left > unanswered. I too thought that the goal of this sub-WG (?) was to > come up > with a set of requirements. While I do not question the technical > soundness > of the proposals (not requirements) that this sub-WG has defined, I > still > do not understand the process through which the goals for the sub-WG > were > set, and how the sub-WG was formed. > > I also do not understand how the WG can benefit in the long > run from this > seemingly closed process where no real discussion has taken place on > the > technical merits (or lack of thereof, for what matters) of the IDs > that > were left out. > > Would someone please comment on this? > > Thanks > Luca > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 09:55: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 JAA11438 for ; Tue, 3 Oct 2000 09:55:01 -0400 (EDT) Received: from standards (47.234.32.16:4846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B3EA@standards.nortelnetworks.com>; Tue, 3 Oct 2000 9:38:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12523 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 09:38:29 -0400 Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B3CC@standards.nortelnetworks.com>; Tue, 3 Oct 2000 9:28:29 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id GAA12151 for ; Tue, 3 Oct 2000 06:42:53 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id GAA12163 for ; Tue, 3 Oct 2000 06:42:52 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Oct 2000 08:42:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: Date: Tue, 3 Oct 2000 08:42:29 -0500 Reply-To: Roberts Philip-qa3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Philip-qa3445 Subject: Re: [MOBILE-IP] Fast Handoff v4 archives available X-To: Luca Salgarelli To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Luca, > ---------- > From: Luca Salgarelli > Reply To: Luca Salgarelli > Sent: Tuesday, October 3, 2000 4:46 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Fast Handoff v4 archives available > > Basavaraj, Andrew, > > I would like to add some comments to what Andrew wrote. > > > Regards the process: I thought the idea was to come up with a set of > > requirements, then a strawman proposal that sort consensus and met the > > requirements? > > > > It looks like the starting point was too narrow? > > > > It looks like the output from the design team resulted in deltas to > > existing IDs? (Why are these two IDs technically superior to others?). > > > > In addition, weeding out some IDs because they didn't support tunneling > > (e.g., Hawaii) or MIP messaging (e.g., CIP), etc. was a bad call in a > > process that should have been open and inclusive and now looks like on > > the surface to have preselected two IDs (i.e., fast handoff/ proactive > > IDs) that have not been proven "better" than others. > > I completely agree with Andrew. Several weeks ago I wrote a message to the > WG asking clarifications about this process, but those questions were left > unanswered. I too thought that the goal of this sub-WG (?) was to come up > with a set of requirements. While I do not question the technical > soundness > of the proposals (not requirements) that this sub-WG has defined, I still > do not understand the process through which the goals for the sub-WG were > set, and how the sub-WG was formed. > > I also do not understand how the WG can benefit in the long run from this > seemingly closed process where no real discussion has taken place on the > technical merits (or lack of thereof, for what matters) of the IDs that > were left out. > > Would someone please comment on this? > Of course! There were enough drafts dealing with the problem presented at the last IETF. The authors of all of those drafts got together and came up with some agreements about what we wanted to do about fast handoff in a meeting outside the MIP working group meeting. The outcome of those authors discussions were presented to the working group and the entire working group was asked for comment. This is recorded in the minutes of the working group meeting. You can review those if you weren't at the meeting in Pittsburgh. Among the conclusions reached were that the WG would like to see two drafts for fast handover - one for IPv4 and one for IPv6 - and that a design team was being formed to look at each. The IPv4 design team has pretty much concluded its work and is coming back to the working group with two drafts. (A previous post pointed to the archive of the minutes for you to review the discussions that went on in these meetings.) In brief the outcome was that 3 drafts were merged into a single draft (Calhoun, et. al.) and another draft was revised (Soliman and El Malki). The design team could not reach consensus on selecting just one of these. So it is now up to the working group to pick a single draft. If there are aspects of the problem that are not covered by either of the existing drafts it is time for members of the working group to speak up. The latest versions of both drafts have been posted. The IPv6 design team is just about to begin its work. It seems to me that the problem is fairly well understood, but if it becomes apparent from the WG discussion that there is something that is being missed it will be taken into consideration. Hope this helps, Phil > Thanks > Luca > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 10:22: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 KAA12315 for ; Tue, 3 Oct 2000 10:22:25 -0400 (EDT) Received: from standards (47.234.32.16:4846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B435@standards.nortelnetworks.com>; Tue, 3 Oct 2000 10:05:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12653 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 10:05:56 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B434@standards.nortelnetworks.com>; Tue, 3 Oct 2000 10:05:55 -0400 Received: from comet.columbia.edu (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id KAA26085; Tue, 3 Oct 2000 10:20:11 -0400 (EDT) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <976F7C55E3B2D111A0720008C728549C048772E7@en0060exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39DA1934.2147DF89@comet.columbia.edu> Date: Tue, 3 Oct 2000 10:36:52 -0700 Reply-To: campbell@comet.columbia.edu Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Andrew T. Campbell" Organization: Center for Telecommunications Research Subject: Re: [MOBILE-IP] Are requirements required? X-To: "Casati, Alessio (Alessio)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Alessio: "Casati, Alessio (Alessio)" wrote: > > I think I could start writing the requirements right now: > From the right ;-) > 1) the solution MUST NOT suck (for a definition of "suck", > consider the scalability of host based routing) And on the left ... Per-host routes in the "wireless access network" (not the Internet) are required (in my estimation) for a number of reasons: basis for fast handoff control, aggregated micro-QOS to the host, etc. CIP is a proponent of this approach and its highly scalable. Can you shine some light on your view? Its easy to say 'not scalable' but please back that claim up? > 2) the solution MUST be based on tunnels, since this is the way mobile IPv4 > works Why? Hawaii and CIP don't carry the overhead of tunneling or address translation to deliver data in the access network, nor need to be aware of a tree structure of FAs. What is the basis for such religion? On a related note. If the working group will only entertain work items that include tunneling, MIP messaging, etc., then that will limit any innovation of this group in the long term. Its a hard line (MIPv4/ MIPv6 and nothing else). What happens if the carriers decide that MIP will never work and seek alternatives? Should we simply keep working on say (lateral point) "ATM" in the hope that ATM one day get deployed to the desk top once the carriers 'get it'. (BTW, I don't mean to slur MIP by attaching its name to ATM - just to illustrate my point). How else should be scope our work for acceptability by the polit bureau ;-) May be the chairs can tell us what assumptions to base our research on. > 3) the solution MUST NOT be based on host routing (missing this, requirement Your repeating yourself old chap. > 1) would be violated) ? > 4) the solution MUST include security mechanisms that work fine and fast. This is an important one. I'd add: The solution should have a security model that operates on the timescales of fast handoff (extreme case - that can be very fast in pico-nets). AAA may not work at such speeds? CIP has a light weight/ fast and secure model that is tailored to delivering performance securrity at fast handoff speeds. > 5) the solution MUST be fast/low interruption. Agree. > 6) During handoff it MUST be possible to transfer some info to the new FA. Only in the case of buffering and forwarding between FAs during handoff - does that motivate your comment? I must say that all the explicit signaled seamless handoff proposals seem very complex - the exchange of "state" between FAs may not scale? My feeling is that fast handoff with low loss should be the first order goal. Zero loss requires lots of additional buffering, synchronization and signaling: it will not fly and may be unscalable. > 7) queries to AAA servers MUST be minimized Faster is the issue. If AAA (control) is slow then we are not going to deliver better performance on the data path > ... > > do we have to read this from an ID? > > Or, wouldn't it be faster to build on what some colleagues have written > in some documents, and try to improve them if possible? > That is send comments to the list/authors??? Thanks for your mail. While we agree/disagree on some points, its healthy and open to discuss the pros/cons. > > $ 2/100 > > alessio > > > ---------- > > From: Mohamed Khalil[SMTP:mkhalil@NORTELNETWORKS.COM] > > Reply To: Mohamed Khalil > > Sent: 02 October 2000 23:30 > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: [MOBILE-IP] Fast Handoff v4 archives available > > > > Hello folks, > > > > I agree with all completely. As a participant of the handoff meetings at > > the last IETF I was expecting to follow the engineering approach (Since we > > are all belong to the Internet Engineering Task Force) of coming up with a > > set of requirements for IPv4 then we propose different solutions which > > satisfy those requirements. Unfortunately, this never happened. > > > > MK > > > > -----Original Message----- > > From: Akhtar, Haseeb [RICH1:IP30-M:EXCH] > > Sent: Monday, October 02, 2000 4:06 PM > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: [MOBILE-IP] Fast Handoff v4 archives available > > > > > > > > Hello folks, > > > > Ditto. The requirements should have come first before the solution! > > > > Regards, > > > > Haseeb > > > > -----Original Message----- > > From: Luca Salgarelli [SMTP:lsalgarelli@BELL-LABS.COM] > > Sent: Monday, October 02, 2000 3:47 PM > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: [MOBILE-IP] Fast Handoff v4 archives available > > > > Basavaraj, Andrew, > > > > I would like to add some comments to what Andrew wrote. > > > > > Regards the process: I thought the idea was to come up > > with a set of > > > requirements, then a strawman proposal that sort consensus and met > > the > > > requirements? > > > > > > It looks like the starting point was too narrow? > > > > > > It looks like the output from the design team resulted in deltas > > to > > > existing IDs? (Why are these two IDs technically superior to > > others?). > > > > > > In addition, weeding out some IDs because they didn't support > > tunneling > > > (e.g., Hawaii) or MIP messaging (e.g., CIP), etc. was a bad call > > in a > > > process that should have been open and inclusive and now looks > > like on > > > the surface to have preselected two IDs (i.e., fast handoff/ > > proactive > > > IDs) that have not been proven "better" than others. > > > > I completely agree with Andrew. Several weeks ago I wrote a > > message to the > > WG asking clarifications about this process, but those questions > > were left > > unanswered. I too thought that the goal of this sub-WG (?) was to > > come up > > with a set of requirements. While I do not question the technical > > soundness > > of the proposals (not requirements) that this sub-WG has defined, I > > still > > do not understand the process through which the goals for the sub-WG > > were > > set, and how the sub-WG was formed. > > > > I also do not understand how the WG can benefit in the long > > run from this > > seemingly closed process where no real discussion has taken place on > > the > > technical merits (or lack of thereof, for what matters) of the IDs > > that > > were left out. > > > > Would someone please comment on this? > > > > Thanks > > Luca > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 10:49: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 KAA13028 for ; Tue, 3 Oct 2000 10:49:28 -0400 (EDT) Received: from standards (47.234.32.16:4846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B480@standards.nortelnetworks.com>; Tue, 3 Oct 2000 10:32:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12752 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 10:32:52 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B47F@standards.nortelnetworks.com>; Tue, 3 Oct 2000 10:32:52 -0400 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA04019; Tue, 3 Oct 2000 08:47:14 -0600 (MDT) 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 HAA28810; Tue, 3 Oct 2000 07:47:13 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA12037; Tue, 3 Oct 2000 07:47:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Tue, 3 Oct 2000 07:45:07 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Are requirements required? X-To: campbell@comet.columbia.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <39DA1934.2147DF89@comet.columbia.edu> > > > 2) the solution MUST be based on tunnels, since this is the way mobile IPv4 > > works > > Why? > > Hawaii and CIP don't carry the overhead of tunneling or address > translation to deliver data in the access network, nor need > to be aware of a tree structure of FAs. What is the basis for > such religion? > > On a related note. If the working group will only entertain work items > that include tunneling, MIP messaging, etc., then that will limit > any innovation of this group in the long term. Its a hard line (MIPv4/ > MIPv6 and > nothing else). What happens if the carriers decide that MIP > will never work and seek alternatives? Should we simply keep working on > say (lateral > point) "ATM" in the hope that ATM one day get deployed to > the desk top once the carriers 'get it'. (BTW, I don't > mean to slur MIP by attaching its name to ATM - just > to illustrate my point). > > How else should be scope our work for acceptability by the > polit bureau ;-) May be the chairs can tell us what > assumptions to base our research on. > This has nothing to do with religion, IMHO, and it also has nothing to do with whether CIP, HAWAII or any other Micro-Mobility protocol is better than Mobile IP. It simply has to do with setting the WG focus. At every IETF, the MIP WG meetings are diluted by contributions that have nothing to do with the Mobile IP protocol. Don't get me wrong, I do believe that CIP et al. are important, but they do not belong in the Mobile IP WG. The chairs have stated this, so it shouldn't be a surprise that the work in the Mobile IP WG is limited to the Mobile IP protocol. Now, what is needed is a new WG where new ideas can be exchanged, and a Micro-Mobility protocol can be created without having to compete with the Mobile IP protocol. I have previously stated that such a new WG is in the process of being created, and the final touches are being done to satisfy IESG comments. So, all I would ask is that you consider bringing your Micro-Mobility work, which hopefully supports fast hand-offs, to this new WG which plans to meet at the December IETF. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 10:49: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 KAA13035 for ; Tue, 3 Oct 2000 10:49:33 -0400 (EDT) Received: from standards (47.234.32.16:4846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B48A@standards.nortelnetworks.com>; Tue, 3 Oct 2000 10:33:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12747 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 10:33:40 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B47B@standards.nortelnetworks.com>; Tue, 3 Oct 2000 10:23:39 -0400 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Tue Oct 3 10:37:21 EDT 2000 Received: from valjean.dnrc.bell-labs.com (IDENT:root@valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA10586; Tue, 3 Oct 2000 10:37:20 -0400 (EDT) Received: (from salga@localhost) by valjean.dnrc.bell-labs.com (8.9.3/8.8.7) id KAA27291; Tue, 3 Oct 2000 10:37:20 -0400 Mail-Followup-To: Roberts Philip-qa3445 , MOBILE-IP@standards.nortelnetworks.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Organization: Bell Laboratories Message-ID: <20001003103720.A27155@bell-labs.com> Date: Tue, 3 Oct 2000 10:37:20 -0400 Reply-To: Luca Salgarelli Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Luca Salgarelli Subject: Re: [MOBILE-IP] Fast Handoff v4 archives available X-To: Roberts Philip-qa3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: ; from Philip_Roberts-qa3445@email.mot.com on Tue, Oct 03, 2000 at 08:42:29AM -0500 Hi Phil. I was not in Pittsburgh, so your explanation is most welcome. Still, I don't see why the sub-WG, as a basis for its work, completely ignored other possible starting points for fast-handoffs, namely the ones based on host based routing. In particular, I don't think there has been any technical discussion on the WG mailing-list to justify such weeding. Again, I asked questions about this lack of technical discussion when the re-chartering was being discussed a few weeks ago. Apart from a message from Charlie who said that he was not very comfortable "about disallowing host-route based approaches for Mobile IP", there was no other reply. And now we see that even lacking such technical discussion, we already have selected some solutions. I would be happy to see a sub-WG working to specify requirements, or to evaluate proposals about fast-handoffs (along the lines of what has been done in the AAA WG). But in this case the sub-WG was from the start ignoring solutions based on host-based routing, without any evaluation on the technical merits of such approach. I don't think that such a seemingly closed approach is what I would expect from the IETF. Thanks Luca On Tue, Oct 03, 2000 at 08:42:29AM -0500, Roberts Philip-qa3445 wrote: > Hi Luca, > > > > ---------- > > From: Luca Salgarelli > > Reply To: Luca Salgarelli > > Sent: Tuesday, October 3, 2000 4:46 AM > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: [MOBILE-IP] Fast Handoff v4 archives available > > > > Basavaraj, Andrew, > > > > I would like to add some comments to what Andrew wrote. > > > > > Regards the process: I thought the idea was to come up with a set of > > > requirements, then a strawman proposal that sort consensus and met the > > > requirements? > > > > > > It looks like the starting point was too narrow? > > > > > > It looks like the output from the design team resulted in deltas to > > > existing IDs? (Why are these two IDs technically superior to others?). > > > > > > In addition, weeding out some IDs because they didn't support tunneling > > > (e.g., Hawaii) or MIP messaging (e.g., CIP), etc. was a bad call in a > > > process that should have been open and inclusive and now looks like on > > > the surface to have preselected two IDs (i.e., fast handoff/ proactive > > > IDs) that have not been proven "better" than others. > > > > I completely agree with Andrew. Several weeks ago I wrote a message to the > > WG asking clarifications about this process, but those questions were left > > unanswered. I too thought that the goal of this sub-WG (?) was to come up > > with a set of requirements. While I do not question the technical > > soundness > > of the proposals (not requirements) that this sub-WG has defined, I still > > do not understand the process through which the goals for the sub-WG were > > set, and how the sub-WG was formed. > > > > I also do not understand how the WG can benefit in the long run from this > > seemingly closed process where no real discussion has taken place on the > > technical merits (or lack of thereof, for what matters) of the IDs that > > were left out. > > > > Would someone please comment on this? > > > Of course! > > There were enough drafts dealing with the problem presented at the last > IETF. The authors of all of those drafts got together and came up with > some agreements about what we wanted to do about fast handoff in a meeting > outside the MIP working group meeting. The outcome of those authors > discussions were presented to the working group and the entire working group > was asked for comment. This is recorded in the minutes of the working > group meeting. You can review those if you weren't at the meeting in > Pittsburgh. > > Among the conclusions reached were that the WG would like to see two drafts > for fast handover - one for IPv4 and one for IPv6 - and that a design team > was being formed to look at each. > > The IPv4 design team has pretty much concluded its work and is coming back > to the working group with two drafts. (A previous post pointed to the > archive of the minutes for you to review the discussions that went on in > these meetings.) In brief the outcome was that 3 drafts were merged into a > single draft (Calhoun, et. al.) and another draft was revised (Soliman and > El Malki). The design team could not reach consensus on selecting just one > of these. So it is now up to the working group to pick a single draft. If > there are aspects of the problem that are not covered by either of the > existing drafts it is time for members of the working group to speak up. > The latest versions of both drafts have been posted. > > The IPv6 design team is just about to begin its work. > > It seems to me that the problem is fairly well understood, but if it becomes > apparent from the WG discussion that there is something that is being missed > it will be taken into consideration. > > Hope this helps, > Phil > > > > Thanks > > Luca > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 11:04: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 LAA13484 for ; Tue, 3 Oct 2000 11:04:36 -0400 (EDT) Received: from standards (47.234.32.16:4846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B52C@standards.nortelnetworks.com>; Tue, 3 Oct 2000 10:48:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12980 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 10:48:04 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B52B@standards.nortelnetworks.com>; Tue, 3 Oct 2000 10:48:03 -0400 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 IAA10232; Tue, 3 Oct 2000 08:02:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e93F2MY27262; Tue, 3 Oct 2000 08:02:22 -0700 X-Virus-Scanned: Tue, 3 Oct 2000 08:02:22 -0700 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) smtpdJfMP0b; Tue, 03 Oct 2000 08:02:18 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39D9F4FC.D0354071@iprg.nokia.com> Date: Tue, 3 Oct 2000 08:02:20 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] Are requirements required? X-To: Pat Calhoun To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Pat, > Now, what is needed is a new WG where new ideas can be exchanged, and a > Micro-Mobility protocol can be created without having to compete with the > Mobile IP protocol. I have previously stated that such a new WG is in the > process of being created, and the final touches are being done to satisfy IESG > comments. So, all I would ask is that you consider bringing your > Micro-Mobility work, which hopefully supports fast hand-offs, to this new WG > which plans to meet at the December IETF. Is there a mailing list for this proposed new working group? Your wording about "non-competition" makes me quite nervous. I would infer that some micro-mobility approaches have been somehow disenfranchised because of the action of the mobile-ip working group. However, I don't believe that has occurred. I'm very curious about the proposed charter for this new working group. I also wonder whether considerations about Mobile IP would be excluded from consideration within the new working group, in order to "avoid competition". If so, I think that would be a terrific botch. Is this a minefield? I notice your use of the term "micro-mobility". Do you mean to say mobility between multiple, homogenous network links? Are heterogeneous links excluded? Is handover of interest? Smooth handover? Fast handover? Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 11:13: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 LAA13743 for ; Tue, 3 Oct 2000 11:13:46 -0400 (EDT) Received: from standards (47.234.32.16:4846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B544@standards.nortelnetworks.com>; Tue, 3 Oct 2000 10:51:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12913 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 10:51:30 -0400 Received: from motgate3.mot.com (144.189.100.103:48663) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B4F5@standards.nortelnetworks.com>; Tue, 3 Oct 2000 10:41:29 -0400 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id HAA03401 for ; Tue, 3 Oct 2000 07:53:23 -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 HAA10241 for ; Tue, 3 Oct 2000 07:55:50 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Oct 2000 09:55:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 3 Oct 2000 09:55:28 -0500 Reply-To: Roberts Philip-qa3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Philip-qa3445 Subject: Re: [MOBILE-IP] Fast Handoff v4 archives available X-To: Luca Salgarelli To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Luca, > ---------- > From: Luca Salgarelli > Sent: Tuesday, October 3, 2000 10:37 PM > To: Roberts Philip-qa3445 > Cc: MOBILE-IP@standards.nortelnetworks.com > Subject: Re: [MOBILE-IP] Fast Handoff v4 archives available > > Hi Phil. > > I was not in Pittsburgh, so your explanation is most welcome. > Sorry you missed it and we're glad to be able to help. > Still, I > don't see why the sub-WG, as a basis for its work, completely ignored > other > possible starting points for fast-handoffs, namely the ones based on host > based routing. In particular, I don't think there has been any technical > discussion on the WG mailing-list to justify such weeding. > > Again, I asked questions about this lack of technical discussion when the > re-chartering was being discussed a few weeks ago. Apart from a message > from Charlie who said that he was not very comfortable "about disallowing > host-route based approaches for Mobile IP", there was no other reply. > > And now we see that even lacking such technical discussion, we already > have > selected some solutions. I would be happy to see a sub-WG working to > specify requirements, or to evaluate proposals about fast-handoffs (along > the lines of what has been done in the AAA WG). But in this case the > sub-WG > was from the start ignoring solutions based on host-based routing, without > any evaluation on the technical merits of such approach. > > I don't think that such a seemingly closed approach is what I would expect > from the IETF. > There seem to be two issues here. First the trimming of the charter and second the consideration of proposals for fast handoffs. They could be related in that the two proposals that were removed as working group items are interested in handling handoffs faster. On trimming the charter, neither of the chairs heard a lot of objections from the working group to consolidating the charter. We try to work on a rough consensus and would expect more people in the working group than just the authors of one approach objecting before we could begin to believe the working group as a whole might be concerned about the decision. Let me say it again if I haven't made it clear in the past. We believe this consolidation will allow the working group to focus better on making solutions based on Mobile IP better prepared for deployment. If there is a lot of interest in proposals based on alternate approaches to Mobile IP there may be room somewhere in the IETF for consideration of such proposals. On the issue of fast handoff. You seem mainly to object to the seemingly closed process but again neither chair finds this an easy objection to understand. Anyone who had an I-D on fast handoff was allowed to participate in the meeting in Pittsburgh, the results of that meeting were discussed in the working group meeting itself, it was announced that there were design teams forming and the leaders of the design teams were designated, and the minutes were posted on the list. I'm not sure what else could've been done. Phil > Thanks > Luca > > On Tue, Oct 03, 2000 at 08:42:29AM -0500, Roberts Philip-qa3445 wrote: > > Hi Luca, > > > > > > > ---------- > > > From: Luca Salgarelli > > > Reply To: Luca Salgarelli > > > Sent: Tuesday, October 3, 2000 4:46 AM > > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: [MOBILE-IP] Fast Handoff v4 archives available > > > > > > Basavaraj, Andrew, > > > > > > I would like to add some comments to what Andrew wrote. > > > > > > > Regards the process: I thought the idea was to come up with a set of > > > > requirements, then a strawman proposal that sort consensus and met > the > > > > requirements? > > > > > > > > It looks like the starting point was too narrow? > > > > > > > > It looks like the output from the design team resulted in deltas to > > > > existing IDs? (Why are these two IDs technically superior to > others?). > > > > > > > > In addition, weeding out some IDs because they didn't support > tunneling > > > > (e.g., Hawaii) or MIP messaging (e.g., CIP), etc. was a bad call in > a > > > > process that should have been open and inclusive and now looks like > on > > > > the surface to have preselected two IDs (i.e., fast handoff/ > proactive > > > > IDs) that have not been proven "better" than others. > > > > > > I completely agree with Andrew. Several weeks ago I wrote a message to > the > > > WG asking clarifications about this process, but those questions were > left > > > unanswered. I too thought that the goal of this sub-WG (?) was to come > up > > > with a set of requirements. While I do not question the technical > > > soundness > > > of the proposals (not requirements) that this sub-WG has defined, I > still > > > do not understand the process through which the goals for the sub-WG > were > > > set, and how the sub-WG was formed. > > > > > > I also do not understand how the WG can benefit in the long run from > this > > > seemingly closed process where no real discussion has taken place on > the > > > technical merits (or lack of thereof, for what matters) of the IDs > that > > > were left out. > > > > > > Would someone please comment on this? > > > > > Of course! > > > > There were enough drafts dealing with the problem presented at the last > > IETF. The authors of all of those drafts got together and came up with > > some agreements about what we wanted to do about fast handoff in a > meeting > > outside the MIP working group meeting. The outcome of those authors > > discussions were presented to the working group and the entire working > group > > was asked for comment. This is recorded in the minutes of the working > > group meeting. You can review those if you weren't at the meeting in > > Pittsburgh. > > > > Among the conclusions reached were that the WG would like to see two > drafts > > for fast handover - one for IPv4 and one for IPv6 - and that a design > team > > was being formed to look at each. > > > > The IPv4 design team has pretty much concluded its work and is coming > back > > to the working group with two drafts. (A previous post pointed to the > > archive of the minutes for you to review the discussions that went on in > > these meetings.) In brief the outcome was that 3 drafts were merged > into a > > single draft (Calhoun, et. al.) and another draft was revised (Soliman > and > > El Malki). The design team could not reach consensus on selecting just > one > > of these. So it is now up to the working group to pick a single draft. > If > > there are aspects of the problem that are not covered by either of the > > existing drafts it is time for members of the working group to speak up. > > The latest versions of both drafts have been posted. > > > > The IPv6 design team is just about to begin its work. > > > > It seems to me that the problem is fairly well understood, but if it > becomes > > apparent from the WG discussion that there is something that is being > missed > > it will be taken into consideration. > > > > Hope this helps, > > Phil > > > > > > > Thanks > > > Luca > > > > > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 11:13: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 LAA13749 for ; Tue, 3 Oct 2000 11:13:47 -0400 (EDT) Received: from standards (47.234.32.16:4846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B58C@standards.nortelnetworks.com>; Tue, 3 Oct 2000 10:56:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13106 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 10:56:35 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B589@standards.nortelnetworks.com>; Tue, 3 Oct 2000 10:56:35 -0400 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA15997; Tue, 3 Oct 2000 09:10:56 -0600 (MDT) 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 IAA29555; Tue, 3 Oct 2000 08:10:56 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA12712; Tue, 3 Oct 2000 08:10:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Tue, 3 Oct 2000 08:08:49 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Are requirements required? X-To: "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <39D9F4FC.D0354071@iprg.nokia.com> Sigh, I knew I should have spent hours crafting that e-mail to ensure that it would be completely P/C. However, given the amount of work load I had, I could only afford a short response. Of course, now I will have to spend those hours to do damage control :( :( See my responses below. PatC > > Hello Pat, > > > Now, what is needed is a new WG where new ideas can be exchanged, and a > > Micro-Mobility protocol can be created without having to compete with the > > Mobile IP protocol. I have previously stated that such a new WG is in the > > process of being created, and the final touches are being done to satisfy IESG > > comments. So, all I would ask is that you consider bringing your > > Micro-Mobility work, which hopefully supports fast hand-offs, to this new WG > > which plans to meet at the December IETF. > > Is there a mailing list for this proposed new working group? This is the result of the CRAPS BOF, but with a much more limited scope. The CRAPS mailing list will evolve to the new WG mailing list. > > Your wording about "non-competition" makes me quite nervous. > I would infer that some micro-mobility approaches have been > somehow disenfranchised because of the action of the mobile-ip > working group. However, I don't believe that has occurred. hmmm..... obviously we haven't been reading the same e-mails. The WG chairs have stated that the Mobile IP WG will, from now on, concentrate on Mobile IP protocols, and related enhancements. I used the term "compete" quite loosely, so nothing malicious was intended, and I meant compete for time. The issue, as I stated, is the somewhat limited amount of time and resources in the Mobile IP WG. The new WG is intended to take the work that the Mobile IP WG cannot handle. > > I'm very curious about the proposed charter for this new working > group. I also wonder whether considerations about Mobile IP would > be excluded from consideration within the new working group, in > order to "avoid competition". If so, I think that would be a > terrific botch. Why would you want two WGs to work on Mobile IP? I believe that the Mobile IP WG chairs want to keep all Mobile IP related protocol development, and other non-tunneling mobility protocols would be in the new WG. This is not intended to limit the scope of the Mobile IP protocol in any way, shape, or form, but rather to allow the Mobile IP WG to concentrate on its milestones. > > Is this a minefield? Perhaps it is, and my head blew off.... > > I notice your use of the term "micro-mobility". Do you mean to > say mobility between multiple, homogenous network links? Are > heterogeneous links excluded? Is handover of interest? Smooth > handover? Fast handover? > Sigh. Charlie, how about I make use of the term non-tunneling approaches instead? PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 11:24: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 LAA13988 for ; Tue, 3 Oct 2000 11:24:17 -0400 (EDT) Received: from standards (47.234.32.16:4846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B5DE@standards.nortelnetworks.com>; Tue, 3 Oct 2000 11:02:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13027 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 11:02:07 -0400 Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B548@standards.nortelnetworks.com>; Tue, 3 Oct 2000 10:51:53 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA00085 for ; Tue, 3 Oct 2000 08:06:17 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id IAA02703 for ; Tue, 3 Oct 2000 08:06:17 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Oct 2000 10:05:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: Date: Tue, 3 Oct 2000 10:05:54 -0500 Reply-To: Roberts Philip-qa3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Philip-qa3445 Subject: Re: [MOBILE-IP] Are requirements required? X-To: "campbell@COMET.COLUMBIA.EDU" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > On a related note. If the working group will only entertain work items > that include tunneling, MIP messaging, etc., then that will limit > any innovation of this group in the long term. Its a hard line (MIPv4/ > MIPv6 and > nothing else). What happens if the carriers decide that MIP > will never work and seek alternatives? Should we simply keep working on > say (lateral > point) "ATM" in the hope that ATM one day get deployed to > the desk top once the carriers 'get it'. (BTW, I don't > mean to slur MIP by attaching its name to ATM - just > to illustrate my point). > > How else should be scope our work for acceptability by the > polit bureau ;-) May be the chairs can tell us what > assumptions to base our research on. > > The polit bureau? Really, Andrew? It's not the job of the chairs to tell people what to work on in their labs. Nor is it our job to tell vendors what to build or network operators what to buy and deploy. If your research is so constrained by the charter of a single working group that's your problem not ours. It is however our job to help the working group set objectives and keep the work moving along to reach those objectives. It's been pretty apparent for awhile that we've been entertaining research projects on a number of methods for handling mobility at every IETF meeting and it seems this often detracts from reaching our objectives of getting Mobile IP done. We proposed consolidating the charter on the list and we didn't hear much that would give us the impression the working group as a whole didn't want this. Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 11:24: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 LAA13992 for ; Tue, 3 Oct 2000 11:24:18 -0400 (EDT) Received: from standards (47.234.32.16:4846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B5FB@standards.nortelnetworks.com>; Tue, 3 Oct 2000 11:03:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13256 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 11:03:20 -0400 Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B5FA@standards.nortelnetworks.com>; Tue, 3 Oct 2000 11:03:19 -0400 Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA17866 for ; Tue, 3 Oct 2000 11:17:44 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA17855 for ; Tue, 3 Oct 2000 11:17:43 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Oct 2000 16:17:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C048772EC@en0060exch001u.uk.lucent.com> Date: Tue, 3 Oct 2000 16:17:36 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] Are requirements required? X-To: "campbell@comet.columbia.edu" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > 1) the solution MUST NOT suck (for a definition of "suck", > > consider the scalability of host based routing) > > Per-host routes in the "wireless access network" (not the Internet) are > required (in my estimation) for a number of reasons: basis > for fast handoff control, aggregated micro-QOS to the host, etc. > > CIP is a proponent of this approach and its highly scalable. > > Can you shine some light on your view? Its easy to say > 'not scalable' but please back that claim up? > > I can shed some light on the requirement: I don't want the solution to suck. One good example to give a gist of what I mean by "Suck" is observing the scalability of host routing. I generally come to the conclusion "It SUCKS!" > > 2) the solution MUST be based on tunnels, since this is the way mobile > IPv4 > > works > > Why? > Please have a look at RFC2002. Mobile IP is indeed based on tunnels. Departing from this model is not within the scope of this WG. > On a related note. If the working group will only entertain work items > that include tunneling, MIP messaging, etc., then that will limit > any innovation of this group in the long term. Its a hard line (MIPv4/ > MIPv6 and > nothing else). What happens if the carriers decide that MIP > will never work and seek alternatives? > this is not a problem for us (hic et nunc). > Should we simply keep working on > say (lateral > point) "ATM" in the hope that ATM one day get deployed to > the desk top once the carriers 'get it'. (BTW, I don't > mean to slur MIP by attaching its name to ATM - just > to illustrate my point). > It is a very lateral point... > > 3) the solution MUST NOT be based on host routing (missing this, > requirement > > Your repeating yourself old chap. > > No, unless you think there's a one to one correspondence between 1 and 3. > > 1) would be violated) > ? > Andrew, You must glue this to the end of the line above this line in my original message, for your understanding. Hope this satisfies your "?". > > 6) During handoff it MUST be possible to transfer some info to the new > FA. > > Only in the case of buffering and forwarding between FAs during handoff > - does > that motivate your comment? I must say that all the explicit signaled > seamless > handoff proposals seem very complex - the exchange of "state" between > FAs may not > scale? > ??? If the state scales, its transfer does too. By the way, I was not talking about buffering. Yours, Alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 11: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 LAA14174 for ; Tue, 3 Oct 2000 11:30:12 -0400 (EDT) Received: from standards (47.234.32.16:4846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B690@standards.nortelnetworks.com>; Tue, 3 Oct 2000 11:13:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13453 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 11:13:41 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B68F@standards.nortelnetworks.com>; Tue, 3 Oct 2000 11:13:36 -0400 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 IAA12542; Tue, 3 Oct 2000 08:27:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e93FRrq09574; Tue, 3 Oct 2000 08:27:53 -0700 X-Virus-Scanned: Tue, 3 Oct 2000 08:27:53 -0700 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) smtpds6ovL3; Tue, 03 Oct 2000 08:27:49 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39D9FAF8.3E552D1E@iprg.nokia.com> Date: Tue, 3 Oct 2000 08:27:52 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] Are requirements required? X-To: Pat Calhoun To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Pat, Sorry if I pushed the wrong buttons. I'm not trying to be discouraging or aggravating, just really wanting to understand what the issues are. >> Is there a mailing list for this proposed new working group? > > This is the result of the CRAPS BOF, but with a much more limited scope. The > CRAPS mailing list will evolve to the new WG mailing list. Could you post a pointer to the CRAPS mailing list for those archive-averse among us? (o.k. I'm being lazy.) >> I'm very curious about the proposed charter for this new working >> group. I also wonder whether considerations about Mobile IP would >> be excluded from consideration within the new working group, in >> order to "avoid competition". If so, I think that would be a >> terrific botch. > > Why would you want two WGs to work on Mobile IP? I believe that the Mobile IP > WG chairs want to keep all Mobile IP related protocol development, and other > non-tunneling mobility protocols would be in the new WG. This is the heart of the matter. Of course you are right that there should not be two working groups standardizing the same protocols. However, depending upon its charter, the new working group may end up designing protocols that should be made to work well with Mobile IP. That seems to me to indicate that some consideration should be given to Mobile IP within the new working group, even if the new working group does not work on Mobile IP. There also might be some overlap with recent "seamless handover" efforts from the IPv4 and IPv6 design teams. Would the new working group spend any focus on feature-specific context handover? >> I notice your use of the term "micro-mobility". Do you mean to >> say mobility between multiple, homogenous network links? Are >> heterogeneous links excluded? Is handover of interest? Smooth >> handover? Fast handover? > > Sigh. Charlie, how about I make use of the term non-tunneling approaches > instead? It seems to me that both tunneling and non-tunneling approaches are fair game in Mobile IP and in the new working group, so that does not seem to be the dividing line. Is source routing considered to be tunneling? Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 11:37: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 LAA14352 for ; Tue, 3 Oct 2000 11:37:14 -0400 (EDT) Received: from standards (47.234.32.16:4846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B6C6@standards.nortelnetworks.com>; Tue, 3 Oct 2000 11:19:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13525 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 11:19:01 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B6C5@standards.nortelnetworks.com>; Tue, 3 Oct 2000 11:19:01 -0400 Received: from comet.columbia.edu (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id LAA29032; Tue, 3 Oct 2000 11:33:22 -0400 (EDT) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <976F7C55E3B2D111A0720008C728549C048772EC@en0060exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39DA2A5C.E719CB8B@comet.columbia.edu> Date: Tue, 3 Oct 2000 11:50:04 -0700 Reply-To: campbell@comet.columbia.edu Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Andrew T. Campbell" Organization: Center for Telecommunications Research Subject: Re: [MOBILE-IP] Are requirements required? X-To: "Casati, Alessio (Alessio)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit "Casati, Alessio (Alessio)" wrote: > > > > 1) the solution MUST NOT suck (for a definition of "suck", > > > consider the scalability of host based routing) > > > > Per-host routes in the "wireless access network" (not the Internet) are > > required (in my estimation) for a number of reasons: basis > > for fast handoff control, aggregated micro-QOS to the host, etc. > > > > CIP is a proponent of this approach and its highly scalable. > > > > Can you shine some light on your view? Its easy to say > > 'not scalable' but please back that claim up? > > > > > I can shed some light on the requirement: > > I don't want the solution to suck. One good example > to give a gist of what I mean by "Suck" is observing > the scalability of host routing. I generally come to the > conclusion "It SUCKS!" You still haven't explained your position. I know per-host routes do not scale in the core network. We al agree on that. And I'm not proposing that. We are discussing edge networks - e.g., wireless access networks. We use per-host routing in Cellular IP access networks for handoff control its very scalable. Now why is the use of per-host routes in such a setting unscalable? Can you provide some insight. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 11:45: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 LAA14614 for ; Tue, 3 Oct 2000 11:45:41 -0400 (EDT) Received: from standards (47.234.32.16:4846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B71D@standards.nortelnetworks.com>; Tue, 3 Oct 2000 11:29:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13639 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 11:29:14 -0400 Received: from auemail2.firewall.lucent.com (auemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B71C@standards.nortelnetworks.com>; Tue, 3 Oct 2000 11:29:14 -0400 Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA03497 for ; Tue, 3 Oct 2000 11:43:38 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA03475 for ; Tue, 3 Oct 2000 11:43:38 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Oct 2000 16:43:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C048772EF@en0060exch001u.uk.lucent.com> Date: Tue, 3 Oct 2000 16:43:34 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] Are requirements required? X-To: "campbell@comet.columbia.edu" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > You still haven't explained your position. > > I know per-host routes do not scale in the core > network. We al agree on that. And I'm not proposing that. > > We are discussing edge networks - e.g., wireless access > networks. > In which case, I think host routing is not technically sound for it is conflicting with the requirement to support Private addresses. And it makes the AN inherenly non multiprotocol. We want to support PPP. > We use per-host routing in Cellular IP access networks > for handoff control its very scalable. > > I should have used "not Technically sound", instead... Andrew, I'm not pointing at any scalability issues, I just wanted to explain the meanung of a word. Is it clear now? I'm sure it is. alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 12:00: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 MAA14950 for ; Tue, 3 Oct 2000 12:00:07 -0400 (EDT) Received: from standards (47.234.32.16:4846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B774@standards.nortelnetworks.com>; Tue, 3 Oct 2000 11:43:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13693 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 11:43:38 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B745@standards.nortelnetworks.com>; Tue, 3 Oct 2000 11:33:37 -0400 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Tue Oct 3 11:47:15 EDT 2000 Received: from valjean.dnrc.bell-labs.com (IDENT:root@valjean [135.180.240.120]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA17585 for ; Tue, 3 Oct 2000 11:47:14 -0400 (EDT) Received: (from salga@localhost) by valjean.dnrc.bell-labs.com (8.9.3/8.8.7) id LAA27891 for MOBILE-IP@standards.nortelnetworks.com; Tue, 3 Oct 2000 11:47:14 -0400 Mail-Followup-To: MOBILE-IP@standards.nortelnetworks.com References: <39D9FAF8.3E552D1E@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Organization: Bell Laboratories Message-ID: <20001003114714.W19948@bell-labs.com> Date: Tue, 3 Oct 2000 11:47:14 -0400 Reply-To: Luca Salgarelli Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Luca Salgarelli Subject: Re: [MOBILE-IP] Are requirements required? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <39D9FAF8.3E552D1E@iprg.nokia.com>; from charliep@IPRG.NOKIA.COM on Tue, Oct 03, 2000 at 08:27:52AM -0700 Hi Pat and Charlie. In my understanding, the whole discussion is starting to appear as a debate about what can be considered "related to Mobile IP". I think that during the re-chartering of the MIP WG, and seemingly the chartering of the new WG, not enough attention has been paid to the specification of what this means. What is "related to Mobile IP"? A protocol that uses the same message format? A protocol that uses some form of IP tunneling? I would be very happy to see a new WG working on fast-handoffs exclusively. However, I too have some doubts about being able to avoid duplication of work between this new WG and the Mobile IP WG. Luca On Tue, Oct 03, 2000 at 08:27:52AM -0700, Charles E. Perkins wrote: > Hello Pat, > > Sorry if I pushed the wrong buttons. I'm not trying to > be discouraging or aggravating, just really wanting to > understand what the issues are. > > >> Is there a mailing list for this proposed new working group? > > > > This is the result of the CRAPS BOF, but with a much more limited scope. The > > CRAPS mailing list will evolve to the new WG mailing list. > > Could you post a pointer to the CRAPS mailing list for those > archive-averse among us? (o.k. I'm being lazy.) > > >> I'm very curious about the proposed charter for this new working > >> group. I also wonder whether considerations about Mobile IP would > >> be excluded from consideration within the new working group, in > >> order to "avoid competition". If so, I think that would be a > >> terrific botch. > > > > Why would you want two WGs to work on Mobile IP? I believe that the Mobile IP > > WG chairs want to keep all Mobile IP related protocol development, and other > > non-tunneling mobility protocols would be in the new WG. > > This is the heart of the matter. Of course you are right that there > should not be two working groups standardizing the same protocols. > However, depending upon its charter, the new working group may end up > designing protocols that should be made to work well with Mobile IP. > That seems to me to indicate that some consideration should be given > to Mobile IP within the new working group, even if the new working > group does not work on Mobile IP. > > There also might be some overlap with recent "seamless handover" > efforts from the IPv4 and IPv6 design teams. Would the new working > group spend any focus on feature-specific context handover? > > >> I notice your use of the term "micro-mobility". Do you mean to > >> say mobility between multiple, homogenous network links? Are > >> heterogeneous links excluded? Is handover of interest? Smooth > >> handover? Fast handover? > > > > Sigh. Charlie, how about I make use of the term non-tunneling approaches > > instead? > > It seems to me that both tunneling and non-tunneling approaches are > fair game in Mobile IP and in the new working group, so that does > not seem to be the dividing line. Is source routing considered to > be tunneling? > > Regards, > Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 12: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 MAA15133 for ; Tue, 3 Oct 2000 12:07:52 -0400 (EDT) Received: from standards (47.234.32.16:4846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B7A8@standards.nortelnetworks.com>; Tue, 3 Oct 2000 11:49:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13823 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 11:49:44 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B7A7@standards.nortelnetworks.com>; Tue, 3 Oct 2000 11:49:43 -0400 Received: from comet.columbia.edu (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id MAA00547; Tue, 3 Oct 2000 12:04:01 -0400 (EDT) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39DA318B.428A15BE@comet.columbia.edu> Date: Tue, 3 Oct 2000 12:20:43 -0700 Reply-To: campbell@comet.columbia.edu Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Andrew T. Campbell" Organization: Center for Telecommunications Research Subject: Re: [MOBILE-IP] Are requirements required? X-To: Roberts Philip-qa3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Phil: Roberts Philip-qa3445 wrote: > > > On a related note. If the working group will only entertain work items > > that include tunneling, MIP messaging, etc., then that will limit > > any innovation of this group in the long term. Its a hard line (MIPv4/ > > MIPv6 and > > nothing else). What happens if the carriers decide that MIP > > will never work and seek alternatives? Should we simply keep working on > > say (lateral > > point) "ATM" in the hope that ATM one day get deployed to > > the desk top once the carriers 'get it'. (BTW, I don't > > mean to slur MIP by attaching its name to ATM - just > > to illustrate my point). > > > > How else should be scope our work for acceptability by the > > polit bureau ;-) May be the chairs can tell us what > > assumptions to base our research on. > > > > > The polit bureau? Really, Andrew? No offense - My comment is statirical. Being Chair is a not a thankless job. Thanks. > > It's not the job of the chairs to tell people what to work on in their labs. > Nor is it our job to tell vendors what to build or network operators what to > buy and deploy. If your research is so constrained by the charter of a > single working group that's your problem not ours. > > It is however our job to help the working group set objectives and keep the > work moving along to reach those objectives. It's been pretty apparent for > awhile that we've been entertaining research projects on a number of methods > for handling mobility at every IETF meeting and it seems this often detracts > from reaching our objectives of getting Mobile IP done. We proposed > consolidating the charter on the list and we didn't hear much that would > give us the impression the working group as a whole didn't want this. > > Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 14:13: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 OAA20176 for ; Tue, 3 Oct 2000 14:13:54 -0400 (EDT) Received: from standards (47.234.32.16:2614) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B8BA@standards.nortelnetworks.com>; Tue, 3 Oct 2000 13:57:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14158 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 13:57:37 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B8B8@standards.nortelnetworks.com>; Tue, 3 Oct 2000 13:57:36 -0400 Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Tue Oct 3 14:11:53 EDT 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by scummy; Tue Oct 3 14:11:52 EDT 2000 Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP id 1D9A15701F for ; Tue, 3 Oct 2000 13:11:51 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <88256967.0055C6A5.00@hqoutbound.ops.3com.com> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20001003181152.1D9A15701F@king.research.bell-labs.com> Date: Tue, 3 Oct 2000 13:11:52 -0500 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: Re: [MOBILE-IP] Comments on draft-calhoun-mobileip-proactive-fa-02.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit Hi, all, "pcalhoun@eng.sun.com" (psc) writes: >> >> >> 1). Sec 1.2 says "MNs connect to FAs via direct, link layer connections. > I disagree, this is not necessary nor desirable in all cases. The > FA in theory could gain access to "subtending" link layer info > through a variety of mechanisms. Why must it be assumed that the FA > is co-located with the link layer equipment? psc> If there is another layer of abstraction, and the trigger makes psc> it to the FA, then we are happy. I am not really sure that we psc> need to go there in the document, but if you feel that strongly psc> about it, I can add such text. Right, the document just makes the "link layer connectivity" abstraction, which means that MNs are link-layer addressable and reachable from the FA. How you actually implement that abstraction is another question, and I don't see any need for the document to go deeper into it. > 2). In the discussion of the triggering mechanism. FA handover > candidates should be configurable and/or discoverable automagically, > allowing active sets of overlapping coverage areas (more on this > below). psc> good because more is needed in order for me to decode your comment :) It sounds like Phil is asking for the draft to support soft handoff. I strongly disagree with this - soft handoff is a technology-specific thing that should take place underneath Mobile IP. The "proactive" draft is designed with "hard handoff" between the FAs in mind. >> 3). In 1.2 "problems that must be addressed" section under (1). Why worry >> about >> registration? Can't we just go ahead and perform the handoff and >> register in >> parallel? If the registration fails then boot the MN, but get the >> traffic going first >> at all costs. psc> exactly what our draft does. We simply listed the issues that we psc> know of in that section. We could add a "Get data to new cell psc> before registration", but it is covered elsewhere and if you psc> notice, each one of those bullets has a corresponding section. Right, I believe the draft provides exactly the "register in parallel" solution. >> 4). In section 1.2 sub 3, we should allow bi-cast, and tri-cast to all the >> candidate FAs that >> were "discovered" as descibed in 2 above. Gee, this is starting to >> sound like >> OBAST! :-) psc> So you must like it, then :) Again, we are not trying to reinvent soft handoff! If you want to do that in the new working group, go ahead, but it is underneath what we are trying to accomplish. We are adding mechanisms to support fast hard handoff between two different network attachment points. >> 5). In sec 1.2 sub 6., mobile power consumption can be reduced by having >> MORE >> FAs listening and performing selection at the anchor FA. Yikes, this >> smells of >> OBAST! :-) psc> see above comment See my above comments - this is not about frame selection! >> 6). In sec 2.1 the GFA in theory could be co-located with the one of the two >> bi-casting >> FAs. This would reduce the box count (and this is what OBAST does >> with its >> call anchor). psc> I agree, and we support both what we call anchor FA and GFA. We psc> needed to support both of these modes to comply with the Regional psc> Registration I-D. Personally, I would prefer NOT to support GFA psc> directly, but only the anchor mode. If a GFA is deployed in the psc> network, it would be used by the anchor FA (not the new FA). psc> IMHO, this would really simplify the I-D. I also think that anchor is more important than GFA, and I'm glad we support AFA and wouldn't mind removing GFA support. However, given that it's so trivial to support (just put the GFA address in the Update message) and given that there is a constituency, I think it's best to leave it in. >> 7). With respect to Movement detection, could we not generalize this >> coverage >> detection? The MN knows its in the coverage are of a collection of >> subnets >> and can establish new FA relationships with each new subnet, >> selectively >> dropping the old FA relationships as that coverage disappears. Why >> can't >> traffic be deliverec while registration is occuring? Presumably the >> MN already >> has connections with other hosts that are valid. psc> Not sure I understand your comment, because the way I read it, the draft psc> already does this. Again, Phil is trying to do soft handoff in the framework of our draft. Our draft is intended for hard handoff. We do not assume that the MN has the ability to talk to more than one FA at any given moment - in other words, the FA is behind the frame selector. I do not think other approaches make sense. >> 8). If a new link layer is detected by a MN it could tell its current FA >> about it >> and the FA would know about all valid hand off candidates for that link >> type >> due to hand off candidate discovery as described in 2 above. psc> and this information is sent in the air interface message, right? Are you psc> proposing that this also has to be sent in the layer 3 (Mobile IP) message? The "trigger" for the handoff could be based on power measurements as Phil states - but that's a link-layer mechanism, and I don't think we should go extending Mobile IP with a candidate list and/or power measurements. That's the job of the link layer. >> //BEGIN (:-)) >> For those of you born after about 1980, Phil is starting to sound like a >> piece of vinyl with grooves encoded with music that would often get cross >> threaded causing the needle to play the same grooves of music over and over >> again. //END (:-)) psc> Yeah, and I had to trash all my vinyls about 6 months ago.... :) >> >> 9). It would not take much of nudge to make this thing work with a >> make-before >> break capability, then I would be happy and probably shut up! Do you >> want >> me take a stab at this? psc> Please do! I would object to attempts to solve the soft handoff problem with this draft. It is intended for network-layer handoff, not link-layer handoff. >> 10). In section 3.1, To avoid ping-ponging we can use the trick CDMA uses. >> USE MAKE BEFORE BREAK, and add and drops multiple simultaneously >> bi-casted, tri-casted call legs! Then thresholds can be added. You >> can >> make decisions like, gee statistically, this particular link layer >> isn't buying >> me squat anymore, i.e. I don't use the packets coming from that link >> layer >> so that active leg can be dropped. psc> but our I-D already does this, right? What is missing? No, our draft does not do this, and shouldn't. We assume that a handoff takes place between two FAs connected to two different radio access networks. This is a hard handoff with no make-before-break support, which contrary to popular belief, is NOT supported by today's cdma air interfaces. >> 11). I take objection to including section 9.0-9.2. All link layers should >> be addressed >> in generalities with maybe a distinction between fixed and wireless >> being allowed. >> Of course I am not a fan of the MIER approach at all. psc> Whether MIER is good or not, it is irrelevant. We have limited psc> address space, and MIER allows us to conserve some space. What, psc> exactly, would you prefer to see in sections 9.0-9.2? The link-layer address can be used as an opaque identifier, and doesn't need to be understood by the FA, so the protocol is not link-layer specific. We just need to maintain a type space to keep the identifiers unique across different technologies. If you have another technology in mind speak up and we can start to fill in the type space. -Pete From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 14:23: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 OAA20392 for ; Tue, 3 Oct 2000 14:23:52 -0400 (EDT) Received: from standards (47.234.32.16:2614) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B911@standards.nortelnetworks.com>; Tue, 3 Oct 2000 14:07:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14161 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 14:07:38 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B8B9@standards.nortelnetworks.com>; Tue, 3 Oct 2000 13:57:37 -0400 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Tue Oct 3 14:10:50 EDT 2000 Received: from blhothuelpc (thuelpc [135.180.240.114]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id OAA29447 for ; Tue, 3 Oct 2000 14:10:49 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <000c01c02d65$0c77ab90$72f0b487@dnrc.belllabs.com> Date: Tue, 3 Oct 2000 14:09:19 -0400 Reply-To: Sandy Thuel Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Sandy Thuel Subject: Re: [MOBILE-IP] Are requirements required? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <39D9FAF8.3E552D1E@iprg.nokia.com> Content-Transfer-Encoding: 7bit Hi all, I am happy to see that we are finally starting to identify the key concerns about the mobile IP WG and the fast-handoff spinoff-WG (for lack of a better name). All boils down to defining clear charters for the mobile IP WG and for the fast handoff spinoff-WG. There is clearly much confusion still to be cleared before we get to that point. I absolutely agree that the mobile IP WG needs to focus its charter to make progress. The WG chairs needed to do something to make this happen and they should be applauded for recognizing this need and taking some action. Taking fast-handoff work off the WG charter is a very sensible solution but it raised the following questions: a) what is and what isn't fast-handoff work? b) what is a reasonable home for the fast-handoff work within the IETF? c) how do we manage the dependencies of fast handoff work on the evolving Mobile IP work? (i.e., how do we handle the coupling between these two WG's avoiding redundancy and other potential problems?) Many of us that have been following the mobileip WG are puzzled by all these questions. Thanks to Pat Calhoun for pointing us to the CRAPS mailing list and for informing us of the plans to get a micro-mobility WG started. This helps answer question (b). Now how can we initiate some healthy, open and technically sound discussions aimed at getting to the heart of these charter-setting problems? Sandy From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 14:42: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 OAA20759 for ; Tue, 3 Oct 2000 14:41:59 -0400 (EDT) Received: from standards (47.234.32.16:2614) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B95F@standards.nortelnetworks.com>; Tue, 3 Oct 2000 14:25:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14382 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 14:25:33 -0400 Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B95E@standards.nortelnetworks.com>; Tue, 3 Oct 2000 14:25:33 -0400 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA19176 for ; Tue, 3 Oct 2000 14:39:58 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA19152 for ; Tue, 3 Oct 2000 14:39:57 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Oct 2000 19:39:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C048772F9@en0060exch001u.uk.lucent.com> Date: Tue, 3 Oct 2000 19:39:50 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] Are requirements required? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Now how > can we initiate some healthy, open and technically > sound discussions aimed at getting to the heart of > these charter-setting problems? > > > It is my understanding that we have no such issue, since everything is clear in the mobile IP WG at this stage. If it is not clear what is going to happen in other yet to be chartered WGs or whether they'll overlap with MIP WG, probably that would be better discussed on other mailing lists, outside this WG. What we need to do here is to solve technical issues in front of the house based on the work of 2 distinct task forces that have been openly managed by the WG chairs. alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 14:49: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 OAA20900 for ; Tue, 3 Oct 2000 14:49:25 -0400 (EDT) Received: from standards (47.234.32.16:2614) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B9A5@standards.nortelnetworks.com>; Tue, 3 Oct 2000 14:33:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14381 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 14:33:16 -0400 Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B95D@standards.nortelnetworks.com>; Tue, 3 Oct 2000 14:23:16 -0400 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id LAA02232 for ; Tue, 3 Oct 2000 11:37:40 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA26848 for ; Tue, 3 Oct 2000 11:37:40 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Oct 2000 13:37:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: Date: Tue, 3 Oct 2000 13:37:09 -0500 Reply-To: Roberts Philip-qa3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Philip-qa3445 Subject: Re: [MOBILE-IP] Are requirements required? X-To: Sandy Thuel To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Hi all, > Hi Sandy, > I am happy to see that we are finally starting to > identify the key concerns about the mobile IP WG > and the fast-handoff spinoff-WG (for lack of a better > name). All boils down to defining clear charters > for the mobile IP WG and for the fast handoff > spinoff-WG. There is clearly much confusion still > to be cleared before we get to that point. > > I absolutely agree that the mobile IP WG needs to > focus its charter to make progress. The WG chairs > needed to do something to make this happen and > they should be applauded for recognizing this > need and taking some action. Taking fast-handoff > work off the WG charter is a very sensible solution > but it raised the following questions: > a) what is and what isn't fast-handoff work? > b) what is a reasonable home for the fast-handoff > work within the IETF? > c) how do we manage the dependencies of fast handoff > work on the evolving Mobile IP work? (i.e., how > do we handle the coupling between these two WG's > avoiding redundancy and other potential problems?) > The mobile IP working group is not taking fast handoff from its charter. We've consolidated the charter to consider mobile IP based approaches only and we hope to end up with two approaches to doing fast handoff based on mobile IP - one for v4 and one for v6. The other working group that is being proposed may investigate alternate approaches that are not based on mobile IP. > Many of us that have been following the mobileip WG > are puzzled by all these questions. Thanks to Pat > Calhoun for pointing us to the CRAPS mailing list and > for informing us of the plans to get a micro-mobility > WG started. This helps answer question (b). Now how > can we initiate some healthy, open and technically > sound discussions aimed at getting to the heart of > these charter-setting problems? > I'm pretty happy with the charter that mobile IP has and I haven't heard a lot of complaints about our charter that make me think that "many" are puzzled. Pat's working hard to get a charter that the IESG is happy with. Why are you confused? > Sandy > Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 15:19: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 PAA21496 for ; Tue, 3 Oct 2000 15:19:47 -0400 (EDT) Received: from standards (47.234.32.16:4341) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9BA0A@standards.nortelnetworks.com>; Tue, 3 Oct 2000 15:03:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14586 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 15:03:36 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B9F7@standards.nortelnetworks.com>; Tue, 3 Oct 2000 14:53:35 -0400 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Tue Oct 3 15:06:28 EDT 2000 Received: from blhothuelpc (thuelpc [135.180.240.114]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id PAA05040; Tue, 3 Oct 2000 15:06:27 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <000f01c02d6c$d1a40880$72f0b487@dnrc.belllabs.com> Date: Tue, 3 Oct 2000 15:04:56 -0400 Reply-To: Sandy Thuel Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Sandy Thuel Subject: Re: [MOBILE-IP] Are requirements required? X-To: Roberts Philip-qa3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit Hi Phil, > The mobile IP working group is not taking fast handoff from its charter. > We've consolidated the charter to consider mobile IP based approaches only > and we hope to end up with two approaches to doing fast handoff based on > mobile IP - one for v4 and one for v6. The other working group that is > being proposed may investigate alternate approaches that are not based on > mobile IP. In my mind, fast-handoff = micro-mobility. In your definition, fast handoff = (some mechanism based on Mobile IP) whereas micro-mobility = (some mechanism not based in Mobile IP). Is this correct? If so, can you explain what are the necessary conditions for a mechanism to be classified as being "based on Mobile IP"? This is too vague. > I'm pretty happy with the charter that mobile IP has and I haven't heard a > lot of complaints about our charter that make me think that "many" are > puzzled. In making this statement, I took the liberty of speaking for a number of people that have verbally expressed their confusion to us. > Pat's working hard to get a charter that the IESG is > happy with. I'm fully behind this. Is there somewhere where we can keep informed of the status of this effort without bugging Pat with email probes? Sandy From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 15:29: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 PAA21726 for ; Tue, 3 Oct 2000 15:29:58 -0400 (EDT) Received: from standards (47.234.32.16:4341) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9BA4F@standards.nortelnetworks.com>; Tue, 3 Oct 2000 15:13:47 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14616 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 15:13:46 -0400 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9BA0C@standards.nortelnetworks.com>; Tue, 3 Oct 2000 15:03:41 -0400 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id MAA27408 for ; Tue, 3 Oct 2000 12:17:45 -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 MAA03116 for ; Tue, 3 Oct 2000 12:17:42 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Oct 2000 14:17:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: Date: Tue, 3 Oct 2000 14:17:19 -0500 Reply-To: Roberts Philip-qa3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Philip-qa3445 Subject: Re: [MOBILE-IP] Are requirements required? X-To: Sandy Thuel To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Hi Phil, > Hi Sandy, > > The mobile IP working group is not taking fast handoff from its charter. > > We've consolidated the charter to consider mobile IP based approaches > only > > and we hope to end up with two approaches to doing fast handoff based on > > mobile IP - one for v4 and one for v6. The other working group that is > > being proposed may investigate alternate approaches that are not based > on > > mobile IP. > > In my mind, fast-handoff = micro-mobility. In your > definition, fast handoff = (some mechanism based on > Mobile IP) whereas micro-mobility = (some mechanism > not based in Mobile IP). Is this correct? If so, > can you explain what are the necessary conditions for > a mechanism to be classified as being "based on > Mobile IP"? This is too vague. > No this isn't correct. Well, the part about what's in your mind is correct I guess. Fast handoff can be done a number of ways. The mobile IP working group is working on it in the context of Mobile IP. If someone somewhere has another way they want to do it that's fine and I think Pat has said the working group he's working on will be welcoming proposals. The problem as I see it is that Mobile IP as it's currently defined will have trouble completing a "handoff" in time to keep from noticing a glitch in service if it's being used to support a realtime service. The efforts underway here are an attempt to improve that situation. I'm sorry if you think saying something is "based on Mobile IP" is too vague. In the past on this list I tried to say we wanted to use existing mechanisms defined for Mobile IP to solve this problem. Other people working on it don't seem to have a problem understanding it so I'm not sure exactly what I need to explain. > > I'm pretty happy with the charter that mobile IP has and I haven't heard > a > > lot of complaints about our charter that make me think that "many" are > > puzzled. > > In making this statement, I took the liberty of > speaking for a number of people that have verbally > expressed their confusion to us. > OK, that's fine. Maybe if they'd express their confusion to the list it would be more productive? > > Pat's working hard to get a charter that the IESG is > > happy with. > > I'm fully behind this. Is there somewhere where we > can keep informed of the status of this effort without > bugging Pat with email probes? > Don't know. Pat? > Sandy > Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 16:04: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 QAA22208 for ; Tue, 3 Oct 2000 16:04:40 -0400 (EDT) Received: from standards (47.234.32.16:4521) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9BABC@standards.nortelnetworks.com>; Tue, 3 Oct 2000 15:48:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14856 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 15:48:22 -0400 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9BABB@standards.nortelnetworks.com>; Tue, 3 Oct 2000 15:48:21 -0400 Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e93K2iP25110; Tue, 3 Oct 2000 23:02:44 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Tue, 3 Oct 2000 14:59:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E387@daeis07nok> Date: Tue, 3 Oct 2000 14:59:20 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] Fast Handoff v4 archives available X-cc: campbell@comet.columbia.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Andrew, Now that I understand your concerns, let me see if I can address them. > >Pat and Basavaraj: > >First, my observations may be completely >unfounded since I have not the experience >of the design team. > The archives provide a good insight into the discussions of the design team. So go ahead and delve into the archives. >While I am not party to the process (and as Pat >points out its easy to say "free beer") I had >greater expectations given the flurry of >activity, ideas and IDs in this space, and the number >of real systems that have been built >and experience gained with. > I am not sure what your expectations were, but you still have the opportunity to express your opinions and problems with the proposals of the design team. >Let me briefly explain my knee jerk >reaction. > >I think there are a number of conclusions one can >draw from reading the archive and the ID on a >technical level and from a process point of >view. > >Regards the process: I thought the idea was to >come up with a set of requirements, then a strawman proposal >that sort consensus and met the requirements? > The idea to create a design team was to speed up the process of getting an I-D with input from most of the people who had an opinion or an idea about handoffs. The design team creation was well advertised at the last IETF and anyone who wanted to contribute to the effort was welcome to participate in the design team. >(Reading between the lines from the archive) > >It looks like the starting point was >too narrow? > The scope of the effort was discussed at IETF48 and presented to the WG. I do not know if the scope was completely understood by all, but I do not think of it as being narrow. Based on the milestone (Dec 00) we had to have focus. >It looks like the output from the design team >resulted in deltas to existing IDs? (Why are these >two IDs technically superior to others?). > The output of the design team is essentially a consensus document(s). No claims of technical superiority to other I-Ds are claimed for the design team outputs. Please feel free to comment and disagree with the results. The intent of publishing the docs to the WG is to initiate a discussion on the solution being presented. >It looks like the process and results are >narrow? Both IDs are complex and coupled far too closely to >the 3G mindset/RANview: 3GPP2 air interface >is only one type of cellular technology and >cellular is only one type of wireless network, etc. > I think the process was quite open and focused. It's now upto the WG members to raise concerns and issues. The issue that you raise here is I guess your opinion and hence should be addressed to the design team. >In addition, weeding out some IDs because >they didn't support tunneling (e.g., Hawaii) >or MIP messaging (e.g., CIP), etc. >was a bad call in a process that should >have been open and inclusive and now looks >like on the surface to have preselected two IDs >(i.e., fast handoff/ proactive IDs) >that have not been proven "better" than others. > The design team had a set of guidelines that they worked under. Ultimately the "better" solution will prevail. The reasons for not considering Hawaii and CIP are based on changes to the charter. >Again, I could be way off here on my reading >of events. > >Finally, I still firmly believe that Mobile IP >will not be widely deployed until >efficient handoff and paging are incorporated. >I just don't think we have moved very far >forward on this. > You believe the solution proposed by the design team is not efficient? >So I'm very supportive of the work but >surprised at the output. > Thank you. Hope to see you provide comments and input to the design team output. >Best, >Andrew -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 18:22: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 SAA24240 for ; Tue, 3 Oct 2000 18:22:24 -0400 (EDT) Received: from standards (47.234.32.16:3714) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9BB9A@standards.nortelnetworks.com>; Tue, 3 Oct 2000 18:05:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15135 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 18:05:45 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:36421) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9BB99@standards.nortelnetworks.com>; Tue, 3 Oct 2000 18:05:43 -0400 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 IAA08375 for ; Wed, 4 Oct 2000 08:17:27 +1000 (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 JAA04800 for ; Wed, 4 Oct 2000 09:19:36 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Oct 2000 09:19:44 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02D88.05BA6E00" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB301@eaubrnt018.epa.ericsson.se> Date: Wed, 4 Oct 2000 09:19:40 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] Are requirements required? 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_01C02D88.05BA6E00 Content-Type: text/plain Hi Sandy, > > The mobile IP working group is not taking fast handoff from its charter. > > We've consolidated the charter to consider mobile IP based approaches > only > > and we hope to end up with two approaches to doing fast handoff based on > > mobile IP - one for v4 and one for v6. The other working group that is > > being proposed may investigate alternate approaches that are not based > on > > mobile IP. > > In my mind, fast-handoff = micro-mobility. In your > definition, fast handoff = (some mechanism based on > Mobile IP) whereas micro-mobility = (some mechanism > not based in Mobile IP). Is this correct? If so, > can you explain what are the necessary conditions for > a mechanism to be classified as being "based on > Mobile IP"? This is too vague. > => I was guessing that's what was on your mind, may I ask why fast handoff = micromobility ? If we can achieve the performance targets that we're aiming for using MIP and some extensions wouldn't that be better and much less complex than inventing new protocols ? Let alon saving years of IETF work ? In the second session for MIP WG in Pittsburgh, Andrew Campbell mentioned that he was a co-author on a paper that did an evaluation / comparison of the various mobility management schemes. I've read that paper, and on the handoff issue, it was concluded that there were no significant differences between HMIP, CIP and HAWAII. Andrew also mentioned that in is presentation. I may also add that the simulations in that paper did not consider the Fast Handoffs draft (draft-elmalki- ...) which adds improvements to standard HMIP. So when I hear this direct association between micro mobility and fast handoffs, I get a bit confused. ------_=_NextPart_001_01C02D88.05BA6E00 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] Are requirements required?

Hi Sandy,


    > The mobile IP working group is = not taking fast handoff from its charter.
    > We've consolidated the charter = to consider mobile IP based approaches only
    > and we hope to end up with two = approaches to doing fast handoff based on
    > mobile IP - one for v4 and one = for v6.  The other working group that is
    > being proposed may investigate = alternate approaches that are not based on
    > mobile IP.

    In my mind, fast-handoff =3D = micro-mobility.  In your
    definition,  fast handoff =3D = (some mechanism based on
    Mobile IP) whereas micro-mobility =3D = (some mechanism
    not based in Mobile IP).  Is = this correct? If so,
    can you explain what are the = necessary conditions for
    a mechanism to be classified as being = "based on
    Mobile IP"?  This is too = vague.

    =3D> I was = guessing that's what was on your mind, may I ask why
    fast handoff =3D = micromobility ?
    If we can achieve = the performance targets that we're aiming for
    using MIP and some = extensions wouldn't that be better and much less
    complex than = inventing new protocols ? Let alon saving years of IETF work ?

    In the second = session for MIP WG in Pittsburgh, Andrew Campbell mentioned
    that he was a = co-author on a paper that did an evaluation / comparison of the = various
    mobility management = schemes. I've read that paper, and on the handoff issue, it was
    concluded that = there were no significant differences between HMIP, CIP and = HAWAII.
    Andrew also = mentioned that in is presentation.
    I may also add that = the simulations in that paper did not consider the Fast Handoffs =
    draft = (draft-elmalki- ...) which adds improvements to standard HMIP.
    So when I hear this = direct association between micro mobility and fast handoffs, I = get
    a bit confused. =



------_=_NextPart_001_01C02D88.05BA6E00-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 18:22: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 SAA24243 for ; Tue, 3 Oct 2000 18:22:25 -0400 (EDT) Received: from standards (47.234.32.16:3714) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9BBA9@standards.nortelnetworks.com>; Tue, 3 Oct 2000 18:06:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15152 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 18:06:48 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9BBA8@standards.nortelnetworks.com>; Tue, 3 Oct 2000 18:06:48 -0400 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA07613; Tue, 3 Oct 2000 16:21:12 -0600 (MDT) 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 PAA16108; Tue, 3 Oct 2000 15:21:12 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA23235; Tue, 3 Oct 2000 15:21:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Tue, 3 Oct 2000 15:19:04 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Are requirements required? X-To: Sandy Thuel To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <000f01c02d6c$d1a40880$72f0b487@dnrc.belllabs.com> > > Pat's working hard to get a charter that the IESG is > > happy with. > > I'm fully behind this. Is there somewhere where we > can keep informed of the status of this effort without > bugging Pat with email probes? > My understanding is that the charter is now complete, and it is scheduled for the next IESG telechat. As soon as I hear anything, I will send the info to this list (and the craps list which will be renamed to follow the new WG name). PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 18:45: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 SAA24410 for ; Tue, 3 Oct 2000 18:45:18 -0400 (EDT) Received: from standards (47.234.32.16:3714) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9BC38@standards.nortelnetworks.com>; Tue, 3 Oct 2000 18:29:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15335 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 18:29:07 -0400 Received: from alemail1.firewall.lucent.com (alemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9BC33@standards.nortelnetworks.com>; Tue, 3 Oct 2000 18:19:07 -0400 Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA08351 for ; Tue, 3 Oct 2000 18:33:32 -0400 (EDT) Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id SAA08347 for ; Tue, 3 Oct 2000 18:33:32 -0400 (EDT) Received: by nwmail.wh.lucent.com (SMI-8.6/EMS-1.5 sol2) id SAA04291; Tue, 3 Oct 2000 18:33:28 -0400 Received: from lucent.com by nwmail.wh.lucent.com (SMI-8.6/EMS-1.5 sol2) id SAA04284; Tue, 3 Oct 2000 18:33:21 -0400 X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Original-CC: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39DA5EB3.62DC4211@lucent.com> Date: Tue, 3 Oct 2000 18:33:23 -0400 Reply-To: Erik Anderlind Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Erik Anderlind Subject: Re: [MOBILE-IP] Are requirements required? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Phil and Basavaray, I have been a (passive) member of the MIP list for many years and was also surprised by the lack of discussions preceding the charter reorientation. With a list as large as the MIP list, I saw no need to add "I agree too" comments to messages that disagreed with the narrow rescoping of the wg without clear discussions of the decision criteria. The comments went unanswered or there was little attempt to answer them. If the objective is to finish off the base work on the MIPv4 and v6 protocols as they stand today, close the wg and deal with other mobility issues in new wgs, that is OK. Is there a desire/policy to not have wg:s active for too long? If the wg is still open to dealing with extensions to MIP, then criteria have to be a lot more specific. On the MIP charter posted at IETF I didn't see anything that mentions handoff at all, except the last milestone which talks about both intra and inter-domain handoff. How some low latency handoff solutions are OK to work on while others are not is a mystery to me. Cutting out certain IDs just before soliciting input for problems they address, was not very elegant. Let's continue the work on making the MIP based mobility solution better so that it will become widely deployed and not just be a solution of last resort. ...Erik Ps. I am not one among those people that have previously expressed concerns to Sandy. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 23: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 XAA28197 for ; Tue, 3 Oct 2000 23:03:13 -0400 (EDT) Received: from standards (47.234.32.16:1812) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9BD5D@standards.nortelnetworks.com>; Tue, 3 Oct 2000 22:46:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15717 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 22:46:52 -0400 Received: from TYO201.gate.nec.co.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9BD54@standards.nortelnetworks.com>; Tue, 3 Oct 2000 22:36:51 -0400 Received: from mailsv4.nec.co.jp ([10.7.68.93]) by TYO201.gate.nec.co.jp (8.9.3/3.7W00052210) with ESMTP id LAA16245 for ; Wed, 4 Oct 2000 11:51:16 +0900 (JST) Received: from msde08.mcs.mt.nec.co.jp (msde08.mcs.mt.nec.co.jp [10.1.61.8]) by mailsv4.nec.co.jp (8.9.3/3.7W-MAILSV4-NEC) with ESMTP id LAA11090 for ; Wed, 4 Oct 2000 11:51:14 +0900 (JST) Received: from MTMCS86 by msde08.mcs.mt.nec.co.jp (8.9.1/3.7W_3.7W) with ESMTP id LAA29256; Wed, 4 Oct 2000 11:52:54 +0900 (JST) References: <000f01c00ee5$92131e40$574845d8@docomousa.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00 (beta 10) Message-ID: <20001004112723.2255.YHASH@mcs.mt.nec.co.jp> Date: Wed, 4 Oct 2000 11:50:57 +0900 Reply-To: HASHIMOTO Yukio Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: HASHIMOTO Yukio Organization: NEC NETWORKS Subject: Re: [MOBILE-IP] Mobile IP Simulation To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <000f01c00ee5$92131e40$574845d8@docomousa.com> Content-Transfer-Encoding: 7bit Hi. Youngjune. I am now using OPNET 6.0. I don't know if the latest version, OPNET 7 has IPv6 and Mobile IP models, but OPNET supports GUI guided programming and a strong debugger. (To make protocol, you just need to make graphical transition diagrams) (To connect 2 nodes, you just need to connect them with your mouse) I feel much easier on OPNET rather than ns-2 because I am not good at programming, ns was hard to learn for me. If you are a strong programmer, ns-2 may provide almost everything you want to do, if not, I recommend OPNET because of its well documented references and easy programming. I heard that the latest version of OPNET supports multi processor enviroment. (One simulation job is shared by multiple processors. it causes faster simulation, I think) -- HASHIMOTO, Yukio yhash@mcs.mt.nec.co.jp System Development Department Mobile Networks Division NEC NETWORKS Tel. +81-3-3798-4624 ext. 116-3240 FAX. +81-3-3798-4626 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 03:15: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 DAA12949 for ; Wed, 4 Oct 2000 03:15:02 -0400 (EDT) Received: from standards (47.234.32.16:1690) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9BF11@standards.nortelnetworks.com>; Wed, 4 Oct 2000 2:58:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16287 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 02:58:34 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9BF0C@standards.nortelnetworks.com>; Wed, 4 Oct 2000 2:48:34 -0400 Received: from egeckeserttcom (ip13.phoenix12.az.pub-ip.psi.net [38.29.124.13]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id CAA10726; Wed, 4 Oct 2000 02:02:46 -0500 (CDT) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7BIT Message-ID: Date: Tue, 3 Oct 2000 23:59:15 -0700 Reply-To: a_z56@YAHOO.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: a_z56@YAHOO.COM Subject: [MOBILE-IP] E-Mail Services X-To: a_z89@yahoo.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7BIT TIRED OF ENDLESSLY POSTING YOUR ONLINE CLASSIFIED AD AND GETTING NO RESULTS? The fact is there are over 7000 such sites scattered about the web and frankly none of them generate enough traffic to be worth your while. Even when someone does find or visits one of these sites, your ad is hopelessly lost in a myriad of similar offerings. Another frustration is search engines. If you are not in the Top 10 forget about high traffic visiting your web site. Not everyone can be in the Top 10 and stay there, when there are estimates of 4 million that have a web pages. You ask, how do we know? That's exactly what we used to do. The greatest way of marketing this century is undoubtedly direct e-mail. It's similar to the postman delivering a letter to your mailbox. There is NO stumbling on to it! The ability to promote your product, service, website, or MLM/Network Marketing opportunity to millions instantly is what advertisers have been dreaming of for over 100 years. We will e-mail your one page promotion to a list of our general addresses. The greatest part is, it's completely affordable. ----------------------------------------------------------------------- NOTICE: No pornography, chain letters, get quick rich, pyramid scheme, or any threatening or questionable materials. Don't even Ask!! ----------------------------------------------------------------------- STANDARD PRICING AND PROCEDURES ----------------------------------------------------------------------- EXTRACTING: Our list of general Internet addreses are actually extracted from the most popular web sites on the Internet. The addresses are verified and run through our purification process. The process includes addresses run against our custom filter of 2,492 keywords to remove as well as through our 192MB remove /flamer list. The EDU, ORG, GOV, Mil, and US domains are removed as well as well as other domains that asked not to receive e-mail. ----------------------------------------------------------------------- SET-UP FEE: $150.00 This will cover the costs of uploading files, Internet Access (ISP), and software set-up. ----------------------------------------------------------------------- EVALUATION: $350.00 (optional) One of our Marketing Specialists will evaluate your sales letter, and offer his/her expertise on how to make it the most successful. ----------------------------------------------------------------------- STANDARD PRICING: (Emails Delivered) 1 Million- $800.00 per 2 Million- $700.00 per 3 Million & up- $600.00 per ----------------------------------------------------------------------- SPECIAL OFFER! This introductory offer of $475.00 includes: 1. Set-Up Fee 2. Evaluation of sales letter 3. 250,000 e-mails delivered ----------------------------------------------------------------------- PAYMENT POLICY All services must be paid in full prior to delivery of advertisement. Under NO CIRCUMSTANCES will any sales or marketing strategies be discussed until payment is received. ----------------------------------------------------------------------- If you are serious about Direct Email Marketing-Fax the following form to (253) 498-4648 ---------------------------------------------------------------------- THIS FORM MUST BE COMPLETELY FILLED OUT! Contact Name: _____________________________________________ Business Name: ______________________________________ Business Type: ______________________________________ # Years in Business: _________________________ Address: _________________________________________________ City: ____________________ State: ______ Zip: ______________ Country: _______________ Email Address: _______________________________________________ Phone: __________________________Fax: ____________________________ ----------------------------------------------------------------------- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 04:03: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 EAA13426 for ; Wed, 4 Oct 2000 04:03:45 -0400 (EDT) Received: from standards (47.234.32.16:4111) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9BF74@standards.nortelnetworks.com>; Wed, 4 Oct 2000 3:46:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16425 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 03:46:56 -0400 Received: from udomain.com.hk (202.181.231.4:1989) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9BF6F@standards.nortelnetworks.com>; Wed, 4 Oct 2000 3:36:51 -0400 Received: from frankie [203.198.151.44] by udomain.com.hk (SMTPD32-5.05) id AD0B183013A; Wed, 04 Oct 2000 15:19:55 +0800 X-Priority: 3 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=XX4D7D4C1C-01614D7DXX Content-Transfer-Encoding: 7bit Message-ID: <200010041521751.SM00356@frankie> Date: Wed, 4 Oct 2000 15:51:26 +0800 Reply-To: info@heaveny.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Janiusli Subject: [MOBILE-IP] Multi colour plastic cover for mobile To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a Multipart MIME message. --XX4D7D4C1C-01614D7DXX Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Heaveny Group Company Limited 300900 Dear Sirs, How are you? Hope this email will find you happy. As you know, we always try to develop new & potential mobile phone accessories to our valuable customers. This time, we would like to introduce our new products to you.............. 1. Multi colour plastic cover for mobile usd 0.50/1000pcs/model Model avalable: 8210/3210/5110/gd90/6150/788/c25/c35/3688v/788 Colour: red/yellow/green/transparent/blue..... If you are interested in the above products, please do not hesiteate to contact the undersign. We will reply you ASAP. We are looking forward to hearing from you and serving you again soon. With our best regards, Janius Li Heaveny Group Company Limited Room 504-5, Technology Plaza 29-35 Sha Tsui Road Tsuen Wan, Hong Kong Tel: 852-24981617 Fax: 852-24981565 Email: janiusli@heaveny.com URL: http://www.heaveny.com (If email :Please reply to janiusli@heaveny.com) (If fax :Please reply to 852-24981565 ) --XX4D7D4C1C-01614D7DXX Content-Type: application/octet-stream Content-Disposition: attachment; filename="8210.jpg" Content-Length: 47722 Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/7RFoUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAA AAEAAgBIAAAAAQACOEJJTQQNAAAAAAAEAAAAeDhCSU0D8wAAAAAACAAAAAAAAAAAOEJJTQQK AAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgABAGxmZgAG AAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0AAAAG AAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///// ////////////////////////A+gAADhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklN BBQAAAAAAAQAAAADOEJJTQQMAAAAAA/YAAAAAQAAAHAAAABGAAABUAAAW+AAAA+8ABgAAf/Y /+AAEEpGSUYAAQIBAEgASAAA//4AJkZpbGUgd3JpdHRlbiBieSBBZG9iZSBQaG90b3Nob3Co IDUuMP/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgR DAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAEYA cAMBIgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEF AQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFR YRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXy s4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgEC BAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPEl BhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG 1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APSOp5j8aporMWWGAT2A55XmOb/jU6qzKvrq raaarHsrcT7nNY4sa923b9PavQvrBZsNZPDGWP8AuLF87+sXe559ztSfM6qDhMpzJJoEREQS B8vF/wB0u6B7v/x3Oqg/zf4u/vWj0j/Gj1XL6li4dzGsqybG1GzQlpfox2rf315n+bJkN5Do 5+as4F5qzsW5rpFN1T/ue138E72wBpY/wpIt+jemZb8vG32Ab2O2OI76B27/ADXLkvrZ9dcz pFNt2KWvc3IGMyv2kfRfY9z9C/c2tm//AK4uj6EYbks7NsB+9rf/ACK8m+vOVtxaByb+oZlz vixuPjNUY4pDHEyOnHxEekz9s8C+hUj5V/hNt/8AjY640bnMZHl/uTs/xt9cOra2EeB/84XB Ot3n4dhr81FjnNfz8R/sUoxx/rf40/8Avlln+Qfb/qj9dMvrePTdktYxz7341lbRwQGOY9ri f3bWLoOu9UPTcMWtLQ+x4raXGAC7Qc/nbtrGLyr/ABfXkU1kjWjquO8f9eoyKj/nemxd99dn zf0SkmGv6hW9x8qj9o/9FJg4rnDiOpjR6wjP0ypcQAInuD+Dyef/AI1up4udk4tdIsZj2vqb Z7QXbD6bn7djtu5zUEf43+qDnGB/tN/9JLgXXi1zrXOG6xznu11l5L/+/KJFrQXWVvZWfovc 0hv+cQncA7y/x5/98tv+VPqfRf8AGrldS6hXgWYVdRua/ZbuJAcxjrocz+W2t3567/p2X9tw qcqAPUbJA4kHadv3L5++rljWfWHpbgZb9spaY8HvFTh/mvXtf1EdP1U6ez/RMNX+Y5zP++og ESuzw1XD/W/etXR//9DtPrU/bWdN0UvO3sf5J/rbV5Hh9XaQ2/G6ViVdwQBP3+ivXfrGN1wY eDWB/nOcxeM9JBrx2seNWFzHeRBLVT4QZZSbJ463P7kWTpHydh31o6tMHEpc2NfcY/qx6ao5 HVMMOD8jouM8uLQXNdtMk6fRpYp6nRVn0G3Lw8fk35NLPve1GGOAIoV5GSN32boDyK8ueWbS fj7/APyK86+tObSzJwqXYVOYbfXax14ENNb9lu0bLPpr0LopmvOPiwH7/VXAfWjFL8npdoGj M7Mpcf8AjK8fKq/6p6ZAA8A19IzEa9si8jSR8Yfk0sfrHUMSpzKMLHqA/MrO0H/NqaoZHWLs xgGb0zHvDZI3ukj+06jcrl1PBA0LR/cqltftOmndHgiDfDr3uTHfRv8A1SycB5yDRgtwtmVQ whry8Os2ZFtTxuDdnpsrs/7cXZfXTI9LJwmASbN7W+AJZbdLv/YdcV9Va4pc8jW/qd0fDGxL Z/6eU1dh9dgD1Ppc/R+047HfC05ON/6MRMRxSibqXtde5kyEVGB8JH8XzPD651AtZdj42LTI lpY0tI/zFoH6wddAJc2hwHIl/B8lk9KrcMZjHCHVlzXDza5zf+qVlwd6rnzz2RljhZuI0Y7I 2T4/Ud3UsJt3TcT1Lsmmuu1gIe1zntDXj2fmfSXq31MsZb0Rr6xtYbHFrYiJh3A/rLyTDrD+ vdLE6U5AyXz+5jtdlWu/s11L1X6gtLfq5jtdyG1k/F1ND3f9UnwiBKBHW+quhf/R7b6xtJuZ HLqyB8Qf/Ml5H9ZMK7o/VstosLacgDKxSK2uY71nfpWOLn1WV11W+oze2u3/AAfs/Sr2Lr9e 67DPDXvNbvgRv/76snqfQOldWY1uXS3KrqduYWuduqeRsc9vo2VWem9v+Ca7+d/0ir44EZMx IuJkNP8AAivJ9MfJ8dPUOqtY2wt21uO1thrhpI5DXu9vtXQ/U/A6h1DrIycog0dNAsMBsG21 rmYrWuYT/Lyf+LqR8b/F91X9pUszSx2Cyxrsm7fu9StrhuZTRU77f6lzPb+kpx/R/wBP/hF2 vTOl4fS8cY1FTMSjc51eO1x0NkB9tjrbLbLLXbW1tc+x/p1+xPNDYIAdfoLdzMwDgta0fdZ/ 5Jcp13Bycro2e6klj8O6nqOPY3aSHVMbi5oc2xzG7W4bmXfy/f8A6Ndd9V5diX2u5dc5nyYA 0LIxMnErx+oV2XV1ZtORFLnv2A+k39Ayz3N3V2b7q7WfTsrstVbGCBhJ7ZCf8Isw19wDrwh8 su6x1kXHHqvde9p2en6LfUn+pUbmO3fmelbaqp6v1myqyz1AWV/TO1gInj2/S/krpOu9F6Xk Guzohr6e4F/2zp9twrfvcQ5tuOcy+nBup+mz9Xto9n+B/wAHWPpuP0boOPXm5v2bP622w20M psdayn2t9IX3VP8AsTnMt32+z17f9H/pKbJMKvRYMGUy4OA8Xk7vQ8GzEvxOn263YWITl+Iy +oWNyLWf1qsZldT1vf4wPVbU66nW2iqu+v8ArUWnJb/57XMfUvKzMrrvpXuL/tL25Fj7Adzn btXtcfzNjNq6n/GM20YVBoc4WXPFJDeXBz2M9P8A656m1QY4mcydBeXCBf8Ae/8AQ2TmY+0R Dfgh0/u8Uv8AnPnH1mxMrp/Vr8jFe+vp/UnjLwHNDXB1eSPtPtq+n+je59b9n83/ANcrWNZk 9Vr2OteWCz6Lnbe374jfX/1xq7LHswqsZ/Q/rHiOprDbBhZTqZvxXWaWu9Jwa+/H3/pWOq/S U2f6Sl/6HLwuj9Exc3Hys/qWNlYVYLn41PqZFuQ4D2M+zPxsRuPS6fezIv3s/wBP/hVeny8o yoR4x+jKI4uMNSMwRvXcHoh6Rj5tWDn9TyjussB6Vgca35MMyXscyf6NjfT/AOMXsP1WY1nT nNbowWFrP6rWV1N/6heRdQzMrMDcrAxn42B04H7L6TJZV7t5tttY37P6rrv8z+b/ANJZZ7F9 XK9nR6CfpWbnu7fScf8AvqjyYjDJiuh6chMf3T+r9JXiQIlWuo17v//S9E600GvGceGZDCfD UOZ/35UGGchpIe5w7uIgA/uWy9z6f+Ce9X+uO24TXfu3VH/ptWO9x9RpDZDSILnzWOPcxm7c 3+Qzao9pn6FPRckfaWwHEiJEQB/Wf6bfV2fn+/3oDi45AMO2lwmYDO30vouss/N/9Rpnvcbg YeQCI3QGCGtbPt/cjZ/LQQ0+uLDWBBncTI/stB+loguD0H1YZHSGP72vsf8Ae9zf++rk8nIO N1LqbW5BoByHh4ZV6xcIbH2mr8/F93sds/RW7/8ASLsfq8I6LiaRNc/eS5eedc6ozB+s3Uar rbsWuyzc22gNJkhoO5ljLGvr/Rfms/nFHoI4f7v/AHLLhiZSyAC9Nv8ACH95o0ZeK3qWU77X 01tZY0Nstx3bCQdfstL/AE/strP8P+m99f8ApVWx8igdcusOV09gDAK7KscuqJlp3Y1P6Jv2 hv8AhbfV/wC3FKnrFf7SybmdUfWyxlTRdfjNc5+w/R/RFnoej/Y+0fQQqOq1V9Ty7n9TcwW7 IyKcZrW2bQea9r31em7/ALe/nH2ICtPM/wAvmbUuO5ek/wA3GOx/qf6l6P6p5D8366+o7Jsy /ToAFtlfowA2x2yur/Rb3f8AXPprd/xktB6PU4jdFzBtmJl9ft3fm7v3lgf4vL25v1rzskX2 5TW0hrLrgGvIEM1Y321t/wBGz9xdB/jLD3fV4MY0vcbWHaAXaAy72hScvQkCTp7+M35SxNPm RUiK2xgV/gPNfWm6x3TKarr+pQx4IxOoY7TtP0XFnU211ue9jf38m311U+snVX5XTRU/rTuo B5aRS7BOMXx+eL3Mr9H02/6P+cVXqvXOn5XS2YmNZ1Rpbs/QZGQy3GaGke1v/aiz09v6v/Nb LE/Wuv42XiVVM6xn5oL63W0W01U6NIfu9asM/WKo/Rfz/wCnWkIEe3cflmT8o/8AVc/+n/ht SweLXcd//Qkn1gyLLOjCv7Vn5lQcxrXHG+x4bQHbW76fs9Xu0/RVNt/nv+LXq/SWbOl4jf8A gWfi0FeLdd6vidRqpqpv6jlXb2k/bHV7QJ/0eOz9Nd7v51e34wDcapo4DGgfcqkxUoAiiBM7 V85h/d/cZR1+j//T9I6wzHswHsyLDSwlu2wAuh0+z2N+l7lzteMGsmnMpeJOhZa0T5Ha9eCJ Krkr7wNr4P0eP3N//C+BfH5fr9H3p1N3e7H++3/0goOxWOj1M2pmuu2u12nj9Bi8ISTc1cEu K6/rXw/4XtepMdxX8vtfqDprcduBQ3GebKWsAY8gguA/OIdC4n614HQbr8p2T1M4tbnfpmOp tftfu/wbq2+79KvFUk7Pw+3ivh3j+/8A+N8C7DfuacW/6NcW/wDW/Se4t6R0Kf0XXai3tupy J/DFUWdI6ET+l65UG99tORP/ALaLiUlG6J46/wAr/wCMvvP1Lxel03h+PmsyXmqKa6mPawM9 nv32MZ7vo+1bX1kqwLcRjcu84x3TVYGufrB3Ncxnu27V82JJ+Ovu5+Wr/r/879Pjc3JfH1+r 6T1LpP1Udk2lvXdmRuPqtdjXxv8AzoIrs/6KzndH6DPu69VH/EZH/vKuHSWliv2ocPv1wx24 eD5f0Pc9fB+61pVxH5d31DoPSvq2z1BV1sWAlpyC3Hu3huuxrN9Vfsd7vzF6vT6fos9P+b2j Z8I9vK+WElUFe/l3v03x37u36X6P+Iy/oj9mz//ZOEJJTQQGAAAAAAAHAAMAAAABAQD/4gxY SUNDX1BST0ZJTEUAAQEAAAxITGlubwIQAABtbnRyUkdCIFhZWiAHzgACAAkABgAxAABhY3Nw TVNGVAAAAABJRUMgc1JHQgAAAAAAAAAAAAAAAAAA9tYAAQAAAADTLUhQICAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFjcHJ0AAABUAAAADNkZXNj AAABhAAAAGx3dHB0AAAB8AAAABRia3B0AAACBAAAABRyWFlaAAACGAAAABRnWFlaAAACLAAA ABRiWFlaAAACQAAAABRkbW5kAAACVAAAAHBkbWRkAAACxAAAAIh2dWVkAAADTAAAAIZ2aWV3 AAAD1AAAACRsdW1pAAAD+AAAABRtZWFzAAAEDAAAACR0ZWNoAAAEMAAAAAxyVFJDAAAEPAAA CAxnVFJDAAAEPAAACAxiVFJDAAAEPAAACAx0ZXh0AAAAAENvcHlyaWdodCAoYykgMTk5OCBI ZXdsZXR0LVBhY2thcmQgQ29tcGFueQAAZGVzYwAAAAAAAAASc1JHQiBJRUM2MTk2Ni0yLjEA AAAAAAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAPNRAAEAAAABFsxYWVogAAAAAAAA AAAAAAAAAAAAAFhZWiAAAAAAAABvogAAOPUAAAOQWFlaIAAAAAAAAGKZAAC3hQAAGNpYWVog AAAAAAAAJKAAAA+EAAC2z2Rlc2MAAAAAAAAAFklFQyBodHRwOi8vd3d3LmllYy5jaAAAAAAA AAAAAAAAFklFQyBodHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQg UkdCIGNvbG91ciBzcGFjZSAtIHNSR0IAAAAAAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1 bHQgUkdCIGNvbG91ciBzcGFjZSAtIHNSR0IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAA AAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAA AAAAAAAALFJlZmVyZW5jZSBWaWV3aW5nIENvbmRpdGlvbiBpbiBJRUM2MTk2Ni0yLjEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHZpZXcAAAAAABOk/gAUXy4AEM8UAAPtzAAEEwsAA1ye AAAAAVhZWiAAAAAAAEwJVgBQAAAAVx/nbWVhcwAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAA Ao8AAAACc2lnIAAAAABDUlQgY3VydgAAAAAAAAQAAAAABQAKAA8AFAAZAB4AIwAoAC0AMgA3 ADsAQABFAEoATwBUAFkAXgBjAGgAbQByAHcAfACBAIYAiwCQAJUAmgCfAKQAqQCuALIAtwC8 AMEAxgDLANAA1QDbAOAA5QDrAPAA9gD7AQEBBwENARMBGQEfASUBKwEyATgBPgFFAUwBUgFZ AWABZwFuAXUBfAGDAYsBkgGaAaEBqQGxAbkBwQHJAdEB2QHhAekB8gH6AgMCDAIUAh0CJgIv AjgCQQJLAlQCXQJnAnECegKEAo4CmAKiAqwCtgLBAssC1QLgAusC9QMAAwsDFgMhAy0DOAND A08DWgNmA3IDfgOKA5YDogOuA7oDxwPTA+AD7AP5BAYEEwQgBC0EOwRIBFUEYwRxBH4EjASa BKgEtgTEBNME4QTwBP4FDQUcBSsFOgVJBVgFZwV3BYYFlgWmBbUFxQXVBeUF9gYGBhYGJwY3 BkgGWQZqBnsGjAadBq8GwAbRBuMG9QcHBxkHKwc9B08HYQd0B4YHmQesB78H0gflB/gICwgf CDIIRghaCG4IggiWCKoIvgjSCOcI+wkQCSUJOglPCWQJeQmPCaQJugnPCeUJ+woRCicKPQpU CmoKgQqYCq4KxQrcCvMLCwsiCzkLUQtpC4ALmAuwC8gL4Qv5DBIMKgxDDFwMdQyODKcMwAzZ DPMNDQ0mDUANWg10DY4NqQ3DDd4N+A4TDi4OSQ5kDn8Omw62DtIO7g8JDyUPQQ9eD3oPlg+z D88P7BAJECYQQxBhEH4QmxC5ENcQ9RETETERTxFtEYwRqhHJEegSBxImEkUSZBKEEqMSwxLj EwMTIxNDE2MTgxOkE8UT5RQGFCcUSRRqFIsUrRTOFPAVEhU0FVYVeBWbFb0V4BYDFiYWSRZs Fo8WshbWFvoXHRdBF2UXiReuF9IX9xgbGEAYZRiKGK8Y1Rj6GSAZRRlrGZEZtxndGgQaKhpR GncanhrFGuwbFBs7G2MbihuyG9ocAhwqHFIcexyjHMwc9R0eHUcdcB2ZHcMd7B4WHkAeah6U Hr4e6R8THz4faR+UH78f6iAVIEEgbCCYIMQg8CEcIUghdSGhIc4h+yInIlUigiKvIt0jCiM4 I2YjlCPCI/AkHyRNJHwkqyTaJQklOCVoJZclxyX3JicmVyaHJrcm6CcYJ0kneierJ9woDSg/ KHEooijUKQYpOClrKZ0p0CoCKjUqaCqbKs8rAis2K2krnSvRLAUsOSxuLKIs1y0MLUEtdi2r LeEuFi5MLoIuty7uLyQvWi+RL8cv/jA1MGwwpDDbMRIxSjGCMbox8jIqMmMymzLUMw0zRjN/ M7gz8TQrNGU0njTYNRM1TTWHNcI1/TY3NnI2rjbpNyQ3YDecN9c4FDhQOIw4yDkFOUI5fzm8 Ofk6Njp0OrI67zstO2s7qjvoPCc8ZTykPOM9Ij1hPaE94D4gPmA+oD7gPyE/YT+iP+JAI0Bk QKZA50EpQWpBrEHuQjBCckK1QvdDOkN9Q8BEA0RHRIpEzkUSRVVFmkXeRiJGZ0arRvBHNUd7 R8BIBUhLSJFI10kdSWNJqUnwSjdKfUrESwxLU0uaS+JMKkxyTLpNAk1KTZNN3E4lTm5Ot08A T0lPk0/dUCdQcVC7UQZRUFGbUeZSMVJ8UsdTE1NfU6pT9lRCVI9U21UoVXVVwlYPVlxWqVb3 V0RXklfgWC9YfVjLWRpZaVm4WgdaVlqmWvVbRVuVW+VcNVyGXNZdJ114XcleGl5sXr1fD19h X7NgBWBXYKpg/GFPYaJh9WJJYpxi8GNDY5dj62RAZJRk6WU9ZZJl52Y9ZpJm6Gc9Z5Nn6Wg/ aJZo7GlDaZpp8WpIap9q92tPa6dr/2xXbK9tCG1gbbluEm5rbsRvHm94b9FwK3CGcOBxOnGV cfByS3KmcwFzXXO4dBR0cHTMdSh1hXXhdj52m3b4d1Z3s3gReG54zHkqeYl553pGeqV7BHtj e8J8IXyBfOF9QX2hfgF+Yn7CfyN/hH/lgEeAqIEKgWuBzYIwgpKC9INXg7qEHYSAhOOFR4Wr hg6GcobXhzuHn4gEiGmIzokziZmJ/opkisqLMIuWi/yMY4zKjTGNmI3/jmaOzo82j56QBpBu kNaRP5GokhGSepLjk02TtpQglIqU9JVflcmWNJaflwqXdZfgmEyYuJkkmZCZ/JpomtWbQpuv nByciZz3nWSd0p5Anq6fHZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum/adu p+CoUqjEqTepqaocqo+rAqt1q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOu tCW0nLUTtYq2AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBw wOzBZ8Hjwl/C28NYw9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21 zjbOts83z7jQOdC60TzRvtI/0sHTRNPG1EnUy9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA 3AXcit0Q3ZbeHN6i3ynfr+A24L3hROHM4lPi2+Nj4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ 6lvq5etw6/vshu0R7ZzuKO6070DvzPBY8OXxcvH/8ozzGfOn9DT0wvVQ9d72bfb794r4Gfio +Tj5x/pX+uf7d/wH/Jj9Kf26/kv+3P9t/////gAmRmlsZSB3cml0dGVuIGJ5IEFkb2JlIFBo b3Rvc2hvcKggNS4w/+4ADkFkb2JlAGQAAAAAAf/bAIQACgcHBwgHCggICg8KCAoPEg0KCg0S FBAQEhAQFBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAELDAwVExUiGBgi FA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM /8AAEQgBCAGpAwERAAIRAQMRAf/dAAQANv/EAaIAAAAHAQEBAQEAAAAAAAAAAAQFAwIGAQAH CAkKCwEAAgIDAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAACAQMDAgQCBgcDBAIGAnMBAgMR BAAFIRIxQVEGE2EicYEUMpGhBxWxQiPBUtHhMxZi8CRygvElQzRTkqKyY3PCNUQnk6OzNhdU ZHTD0uIIJoMJChgZhJRFRqS0VtNVKBry4/PE1OT0ZXWFlaW1xdXl9WZ2hpamtsbW5vY3R1dn d4eXp7fH1+f3OEhYaHiImKi4yNjo+Ck5SVlpeYmZqbnJ2en5KjpKWmp6ipqqusra6voRAAIC AQIDBQUEBQYECAMDbQEAAhEDBCESMUEFURNhIgZxgZEyobHwFMHR4SNCFVJicvEzJDRDghaS UyWiY7LCB3PSNeJEgxdUkwgJChgZJjZFGidkdFU38qOzwygp0+PzhJSktMTU5PRldYWVpbXF 1eX1RlZmdoaWprbG1ub2R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo+DlJWWl5iZmpucnZ6fkq OkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8A7NirsVdiqHlvrSEkSSqCOorU/hlcssY8ykAq Da1py/7tr8lb+mVHVY+9PAVNtf04ftMfkv8AXAdZj708BU28x2I6JIfeg/5qyJ1sP6S8BW/4 lte0Un4f1yP56HdJPhlb/ia3/wB8v94x/PR7pL4ZbHma27wuPkQcfz0e6S+GWx5ls67xSAf7 H/mrD+dh/SXwyqL5j00/aLp81/5p5ZMavGjgKums6W/S5Qf6x4/8SplgzwPWKOEolLq2k+xM jfJgcsEgeRRSpUUr28ckhwIYVBqPEYq3irsVdirsVUZrq2g/vpVT2J3+7IymBzKQFA6vpo/4 +E/HIeNDvTwlY2u6Wv8Au+vyVj/xrkTqMfevAVh8waWP92Mf9i2R/NY+9eArT5j03+Z/+Bx/ NY+9PAXf4j03xf8A4HB+bxrwF3+ItM/mb/gTh/NY+9eAt/4i0v8A34w/2Jx/NY+9eAr017Sm NPXA/wBYMP1jJDUQPVHCUXHd2sgrHMjD2YHLRMHkUUqgg9DXJIbxV2KuxV2KuxV2KtEgCpNB 74q4EHocVaLKOpA+nFWvViH7a/eMFhWvWh/34v3jGwrfqxHo6/eMbCt80/mH342reFW8Vdir sVdirsVdirsVdirsVf/Q7NirsVSnVr9lb6tCaH/djD3/AGcwNXqDH0jm2wjaTSMtKV+LtmrG 5bTsxzWvNFlpVx9Ues1yAC6JsFr9nm575njRjvavESr/AB1bn/j3/wCSn/NmS/JxR4jR88R/ 74QfN2P/ABrh/Kx7v9kvGWv8bp3hT/gmw/lo/wA1HGXf44i7Qr97Y/l4/wA1eM97j54i/wB8 p97Y/l4/zV4z3uHniA9YV/4Jh/DH8tH+avGXHzrb1o0Kj5SH/qnj+Vj3LxlsecdNO7K49lYE figyY08K5Lxl3+MdIBAIl492AVvw+HInSwK+IWTabcLdWyXFrceraSdCpIHurL2b/JyrJh4I 7GTKMrKa213NauJIW2/aXsR75i488oHZsMbZRbXCXMCTR/ZYdPA9xm7hMSFhxyKVcmh2Kpdq +oG0iCRn9/J9n2Hdsx9Rm4B/SZwjbGpJA7EyNykbck7nNOZGRb6pJNa1q10dU+sHlLLUxRL9 ogftH+Vcyo6SxdtZyJEfPMZO1vQeJf8A5tyX5PzR4jj52T+RR82P/NOP5RfEa/xrH3C/ef8A mnH8qO6S+I3/AI0gpvSvz/5sw/lR3SXxFw852vcj/gv+bcfyo7pJ8R3+MrX2/wCCH/NOD8qP 6S+I0fONsewP+zX+mD8r/WXxXf4utevEDxo6H+IycdJEc0HIvTzraxmqs6e6kf8AGr5YNOBy MkcbJNF8y3d9F6tnemSNTRwSWKnwZXrxxlGcRYl/plBBPJN4NTvLeT1BKXqaurGoOYcdTOJu +Js4AWUWd3Hd26zx9DsQeoI6jNvjmJiw0EUVfJodiqE1K/SxtjKd3O0aeLZVlyCEbSBbELq8 luXL3EhZm6DsP9UZqJ5ZSO7eAAll7dwWEPr3cohhY8VLH7R8FUbtlsdPIiwWJmEtHmfR2NBc D5kEYfysu9HGG/8AEekf8tK/Pf8Apj+Vl3rxh3+ItJ/5aU/HD+VPeviNjzBpH/LXH+P9Mfyp 714w2Nf0j/lsj/HB+Wl3rxhePMGlj7N8o+ROH8vPvTxhEQ+bI4GrBqVD4VZh/wACwZclGGUc ijiimUX5gOtOVxbyAdahgf8AhaZeJ5f6DH0omL8ydODBZjDXxEhUf8OvH/hsmMs+sf8AZIoJ pL5qSSIiCFklYfC7UKiv7W32sGTOYjkkRtfpevu8qwXtKuaJKNtz2fKsGqs8Mkyh3J/me1ux V2KuxV//0ezYq7FWKXMvqXEsn8zEj5V2zn9RK5lyoDZLmYmQnsO+RipeM65fSXWsXtxzJDzP x37KeC/8Rzdx5OMUB6sv8xySKaM8v85wqsa8kU05HCtKR1GdWqp3HQ4aWmv0jcV3ONIpsajN 3xpNKq3UjCobAtLvrEv82KtevL/NgQ9E/LS7d7C9t2epSZXC+Adf+bMwtXdBtgziJiQRmsIb wn/l2QmKeOuysGA/1h/zbm10MriQ05RunOZ7U7FWKa/NXUXFa+mqrT6OX/G2ajWy9dORiGyS QyGSdzvmL0ZyDznz/ePJ5gMSsaW8KIfmayf8bLm4wbRDjT5sZ9eX+bLmDf1iUftYrTRuJSeu K0se7kUV2xWlH6/J4DDS0qrdFh2wJpv1m8Biineq3gMVpxlPgMVpmX5a3jJql3ATQSwghfEq 3X/hsxNVIiLZAbvQGlZZ+P7JHTNbVhyAyHyxMfVnhr8JAcD5Gn8cz9DLmGvKGRZsWh2KsY81 TVuIYQfsIWI/1j/zbmt1stwG3GGLI0sl2fgYKooCRtmFezKt2G/mPqD/AF6ysUb4YITK4/yp WIH/AAkWbXADwC2qfNh31iXxy9hTvrMmKad9Zk9sKKa+sSe2BNO+sP4DFaa+sN4DCtO9dvAY Fp3rnwxWneu3hitPU/I+oPd+WoUc1e2eSCp68QQ8Y/2KScc1+qJsBtxpxBOzqQ3Ud8w5imUT b0DTJmnsLeVjVmQcj4kbHN3ilcQWkjdFZYh2KuxV/9Ls2KrZG4xs3gCfuGAqw1Wau3XNDix8 c93KkaCWX0zJDPM52jV2/wCBBzZRwxjyaTK3iZao5E7ncn3O+ZDBQ9U1wrTfqVGKqBWvifbC qkykHfJWhto2Xr3wWlypUVr7UxQq2/U7/IYlVfIq7FWYflvOV1S6t60EsIcD3jan/EZMhOII SC9Mt2YiQHcofwIrmBk0wqw3xmnflqSss6+KqfuJ/wCasn2eeYRmZDmzaHYq8/8AMN8YJb65 6+mXIH+rsP1ZotR6shc3DG6CUeWbq9v7OS6uW+1IVQDYAL/bmZhwgC06oCEuEPMtfuPrOt38 x6NO6j5IfTH/ABDM0OEUuxQ1iq0tsT1GFUPK9R0phVYUYKGPQ4Vcg712xKohD2r0wKvwK7FU 78nTej5lsTWgdjGf9mp/jkJxBFFINPR9b1UaXc2zSx84pg1WHVStP4Nmuy4THk5+nx+ID/RZ V5YlDX5I6PEf1q2Ogl6i0ZhsyzNu4zsVef8AnC99C6vrjqLeOoFepVOn/BZqc8ePMIt0TUWK +UbrUNSN5dXkhdYykUaivEEhnkpX/YZssulhjoANMchLDvOkvq+Zb7eoiZIR8o0Vaf8ABcsR yUpFhtXHFVrGi1G/tirhhV30Yq0xAIFCa4q3irsVdgV6J+WUoew1C2ruk0cn0SIU/XFlObGJ BlE0Uz0zXYpdRm02SH0rmN5EqPst6RKtTw+zzzE1GllCAnfFFnCYJp6f5dfnpMP+SWH/AAxz M0xvGGM+aaZkMHYq7FX/0+zYqhtQfhYzt34EfftleU1EpHNisdKM3gM1mkjuS3TOzHPM0/oe X76WtD6LD/g/h/42zYNTxyVwRQdMkhR+nCls1Sh8exxQplyTXofbCrYAIqe2KrqhqKx2xVSY kEhSaYUNq4AG3xDpiquJdjUbjAQlaJKGuBWTeRZwnmW23/vFkQj5oW/41wFXr1tT1pR/Min9 YyuQ2ZBMvLbUv3X+aM/gRmHotpkNuXkyjNq47R2FcVeVea5/9xd1J+1KwH/BNmkIuduy0wuQ X+WlFv5dgkbaqvKx9iS36s2UOTj6o3kLyCWQyyPKesjM5/2R5fxy1xVmFWt/DbxxVRlck7bf LCFU+o36+JxStUnZXJ9OvTFDTlVf92dvHFXK9NiK0NcVRKuCQPEVwJXYqjNIl9HVrKWtOE8Z r/sgMVeneeIeenW0w/Ymp9DowzFzDZ2PZ59ZH9FknlCblcWTE/bi/HhmHo9sjTnHNnWblw3Y q8r88TBrTVJCftPwB9jIqD8MwMMeLUD+s2SNQQXkSMLoxcinq3Lkn2UJH/xrmy1J9bTDk8y1 G5N3qF1dHrPNJJ9DOWGUMihsKtb9xt2xVxOKrHNCprQdxTrhCthg1RWtOuKt4Fa4jly/a6Vw pcCprQ1AJHSn04q3gVmf5Yz8NWvYO01uG+mN1/6qYDyVG3C/VvPL02Elzy+ieLkf+TmW6gcW lLGG03r3lR+WmFf5JGH3hW/jmHoz+7bcnNO8y2t2KuxV/9Ts2KoHWWA06X34gf8ABDKc59BZ R5sZBpBIT4HMPSjm2TYb59l9PyzcD+do0+9h/TMsNbyUtk1arhV3UYqtoMUN0AFcKtgkgbfT irZAbY4obEQ2xVzk9D0HTAUrK4qm/lWYxeYtOavWZV/4Oqf8bYCr2+1P78e6EfcRlbIJhoTc dVQeIcfgTmDpdspbcn0sszbOOpXLcLaV+nFGNfkMEuSQ8i83uRpAH80i/gC2aaPN2mj+tF3T Gz8oSEGhismp8yn9ubOLgZTci8e9VQoHgMm1UpGQk1rirZl2xVTLE9cKtVxS5t1xQpZJDjiq rCxrQ7gYCle7knAq6KYpIjV+yyt9xrgV7J5oPq+XBJ1o8L/eQP8AjbKMv0udoTWQJj5Ml+DT H9gv/GmYGn2yp1I3L0fN069omgJPQYq8b85zE6TKT1lnQGnuWk/41zE0O+a2WX6UX5fAtPKk Eh2pbzXDf7L1Jf8AiOZWY3MsI8nkQ+yPGmQS7FXYVaxSoStU/LCENwnrU74pVcCuxV2KuxVl H5dSBPMyKf8AdkEy/SAJP+NMB5ITvXv3fnSJj0ZrVvvAT/jXMg76eQY/xh6r5Qb/AES4XwkB p81/szW6L6C35ObIczmp2KuxV//V7NiqW66aWB93UfxzG1R9BZw5sckP+jSfdmLpPpLObBPz IemhIv8APcIPuDHM0c2t5YeuTQ1irdcVb9sVXcCyEj7sbVtDRaHrirTjbbEIaVyMKtlw22KV 8ahkIp0wKq6XJ6Wp2kn8k8bfc64q97tz+/T/AGQ/VlbJG6SaavF/rEfepzX4dszdP6WYZt3G QmqNx065PT92w+8UyGQ+kpjzeR+cm/0GBP5pen0EfxzT4/qdrpOZ/qovzc4h8qXoO37hU+8q mbQOskd3jbZNC1TXChxxVvjTvXFXFe+KtLvirZVT2ocKrfSNKjfG0L1FF6b4Clo7mgxVrcA+ 2KvZ9SPreTfU6n0IJPuMbZRk5FytIayRRXk56Wlgf5ZKfdJmtxn96HI1Q9UnqObx1ildNxtp m/lRj9wOCXJXinnWQrptuv8ANNUj/Vjf/mrMbs3+8J/oss3JM79vq/kqUrtw04KPm0ax/wDG +XTPqKByeTHFDRxV2KrGamFKGatcKFoNMKqsctNjgKq+x3wJdirsVT7yRJw806f/AJTOn/BR SLiUMn84j0vMVlN4xQtX/UmcZkY98Uwxl9QeneUG3vE90P8AxMZqtDyLfkZNmwanYq7FX//W 7NiqWa9/vEo8ZB+psxNX9DOHNjdweMDADw/XmHpsgApskHnn5mTD9G2aVpynJp8kOZ8S1l5s SK5axXJFK/2EZj/kgn9WNpR1toGs3O8VnJxP7TjgPvk45A5IjqtJzbeQtRbi13PHCrdFQGRv +NE/4bKTqY9E8Kax+RLQJRpp28SAq/wbKjqV4StPkTTj9mS4B69VP/GmH8yV4UPN5DqKW103 I7hZEB/FP+ackNT3rwpJdeVdatWJ9D1kH7UR5f8AC/b/AOFy6OaJY0lksEsRpLGyHwZSP15Y CFagbenjhKuiPCZW7qwP3GuKve7eZDLCa9f6ZSTTIBMdNP8AuVgYdDIN/nmvxm8zdL6WZZuX GQOs/wDHMuP9Wn4jKs30FlHm8x8y6bJeW8JiFWhkDFfFajlmpxGi7HDk4b/pRQn5gTKvlm4F ac3iUe/xqf8AjXNpE268vJS1csQ5EkY0VWb5AnFUZb6Nq1yQIbSUg9ypUfe/HIHJEdVTq18h 6xIgkneKCM9q82+5dv8AhspOpinhTWP8vYeNJLmQn/JCqPx5ZWdUvCW/+Vf2a7LNNU7b8T/x rg/NFeFC3PkCQgfVrmrH7IkXb70yY1K8KSXvlfW7AkPB6qj9qI8/+F+3/wALl0c0SghKn5oe MilT4MCD+OWgoaQ/ECPpwqrSAcTt2wK9bEiv5FUkgE2SHf2Uf0ymfIuRpjUwi/KAZLW0Djj+ +JAPgZKjNVA/vA5er3lJ6pm+dWhdTYJp10x6ek/4imQyH0lI5vJ/MumDUbAxqeM0dWgJ2HIj jRv8ls1+lzeHK2zJGw35kWRvK09rAhkmaKGJY1FT8LRc/wDhUbMkZYk82FF5sdI1fotnKT/q 5PxI97Gl8fl/W362pX/WZV/W2DxY96aRcXlPUpP714oR7kufuUf8bZE5wtJtB5FsxGsk88kx PVVog/42b/hsoOpZcKPTyjo0dAbZCTsObMxP3tlZ1Ek8LpPKWjMPis41Hcgsv6mxGoPevCgp vIemzNSFpISRy2YMN/8AjIP+NssGqIRwpRc+TtSt2KwOk6DpX4G+5vh/4fL454lFJbPpWpW5 Pq2sgA/aC8h/wScssE4nqhCEFTRgVPuKfryapr5VkVPMultXpcIP+Cqv/G2PRBZn5zhludU0 5bdDJJ6LVAB2Cyhqse2WY8kYwlZRIEkPRfJ7A3F1ToVUj7zmt0XOTfk6MrzYtLsVdir/AP/X 7NiqV6+aWsY8ZB/xFsw9afR/nNmPmxq7OwzTgt5CQ6skblRIqsB0DKG/4lmRjmWqSVcLdCeM can2RR/DLeMsXGfj0YD2G2DiRTQuFJ3wGSaRSX6CgIqoA29xlZDIFv67ESGINV6UOCk243ys OJHwkb7748K2uW9QdF3oBWvhjSLU5ZVd+QFK9cnE0g7qbcHFHAYHqGFR+OTEmKGfSNKlNXs4 SfHgAf8AhaZMZCFUv8N6EzcjZpX5t/zVkvFl3qy+3oEjoKdAMxZ5CebcAmdmwW9tm/4sT9eD Af3g97KQ2Zpm+cRL9dNNLm9+I/4Zco1B9BZw5sIuqfCPE5pQXKKD1REaJVcBlJ6MAR+OWwkW mSTmG2U7Rxg+PFf6ZbxtbvURenEfIAY8Sti4B74LWkRHe8QoFCAKEeOVkMgVRr1G+0gNDUb4 OFNu+vE7UFDWox4V4m1uwoAC/ZqBX3xpbWyzCUg0oRtUZMbIJtDy29vOOMsaSDwYA/ryYkWK Xy+WtDlNTaID4rVf+InLBll3qpt5R0VhQxOB7O2S8aS0ym0s7eLS47YLWGNAiq2+y9K1zHnm kTTdAI60IHpP4MCfoOVDaQbDyeh5vnCQOuEjSrkj+Wn3kDKs30FlHm87vW4qK9K75poltKlf sBb1pUGnTGB3WXJJ2lFfstT5HLeJrpTMx7K33HG002JnHVT9xwErSul+6EdRxFKU7ZE0kWu/ SRrvQnqKjBSbLv0iTsxFKUII2xoLba6iaUDAdB92Glsue5WRixIr3pkhsxLhIvjk7Q4iNh8Q DDwND+vDxIbgtrUTxusMYcMCrBFqCO4NMTM0kBNbsgSRe5plUZEthZJ5SIW/lXxiNPoZcydG fUUZOTL82TS7FXYq/wD/0OzYqlHmA/uYR/lk/cMwdd9H+c24ubG71lWHkdz0AGarHEyNBvPJ gXnrVr2witHg4AysytyXlsACO+bLFpo9WiUmG/4m1lzxDR19oxl35eDG1w1rXWOzJ/wC4PBx ruqfpbX9hzjr1rwXB4ONNlv9La9Xd4/+BGPgwUkuk1bXVFQ8f/AjD4EEWVE65rv88f8AwIw+ BBHEVRNb14ry5R/8CMHgQW1RNe1/t6R/2P8Azdg8CHmm148xa+oqUiP0f834PAh5pstHzdrC D4oYqeNG/wCa8P5ePei2087aiCKwRH6WH8cfyw75Lb1O2k2iDilQKHtWmYWXAY7huiUyiak0 TVpxdTX5HKMR9Q/rM5cmc50LhpZ5gNNNceLKPxrmNqv7ss8fNhOpPFFAJZG4gMBXvUmgAzTR 3NOYBbH/ADvfXVho6XMFBJ6yp8QqKMG/pmxxaYdXGlJ5+PM+sSHipjqf8gZd+XiwtEDU/MDb 8oh/sRkfCgndf+lNfG3OLf8AycfCh/SRat+kNdpUvD/wJ/rkfCh/STZafUtaVa8oif8AVP8A XD4MPNjxKH6b1wU/uvuP9cPgQ/pLxL01zXCaUi+5v64PAh/STxKo8w62v+6oWPzb+uDwI98l 4l48y62OttER7Mf64fAj3rbv8X6lHu9mtO5DH+mD8uO9NtL56kH2rT7n/wCbcfyx70Wz61vu ehw3jj00ljVzU/Z5+J+nMXJgMd2/GbTKAEQL4jMe920vQ4zWND4gH8M6AOAl3mN+OkyitORQ f8MDlOoPoLKHN5r5k1BLDTWmIDSMypEp6Fif2s1WDGZzpukaCW+ehJD5dmKOyus0K8gSDTkR 2zZY8QHRrMnmizXMjBRK5r/lt/XLeEdzFVEN0T/fP/wTf1wbdyqggvKbTyAf6zf1wbdyqscF 7UD6zL/wbf1wUO5bXtFeqNrqb2+Nv641HuittrFqXEMLuah/y2/rgqPdFbLfLVF/4/Zqf67f 1w8Ee6KLK8trAFRfy/8ABHBwQ7gmysN1ribreufmQf1jHw4dy2XLq+vIpLXRIHiqH9a4PBh3 LZR+h+YdXl1ixtppEeOadI3/AHag8WahoVAwHTwTxM8u51XVbS1kIV5kaSLwYIaOvs2YmTCY RJH0tgNllflZqar84mH4rh0Z9XwXJyZlm1aHYq7FX//R7NiqTeYT8EA92/UMwNd9IbcXNjN2 KqMxNINy25Hn/wCZQ/0OxbwlcfeubSLQWDWK8pDjNATWOEVyq2aIMQqCB2xVwhHIGmC0ENvA CKU+eStih/qlThtC8wALQD5Y2rawgbU374CUhqRAAcFs0JJASpPbJgopKlSsiqO7AfecsYPd UUUQeFafQuUyGzYEXGxHBvkc08dpf5zkdGfDcZ0ThJT5kJ+ooPGQfqbMXV/Q2Y+bznzcxFtZ b0U3cXIf7LNXg+t2OEc/6qB/MpP+dcBHa4j/AONhm4i60vMtPUNcAYz5KGTxwLQbfPMclmF0 tsBJ0p0IGEFrPNe0ANNsFq00CkEU+WG0IRrXc7ZIFC5LUKKkdcSVDXoAnG0qjwAClOmC2QCB njBJAGSCUglAVnA7E5cGL1+7UReRmT/lzjX/AILgMqnycnTC5hMNFlebSbaR92aMVPy2zTHY t2QVIvS7RuVrC3jGp+8DOgjyDrzzSzzSaaYB4yKPwY5j6r6GUObyfz5T9H2f/MSP+IPmP2f9 Z/qssvJU/MDfy5c06CeH/iZzMjzYPMrEVn+Qwy5KE5WMbbZUkqojFBihVjjUN0xtCrJADHXv XHiQ2qIFC7dMCVksAK1wgqpKhO2StXGMU3GC1Q90qrbSN/k5IJUfK37zzPpgHaYH/gQzfwya Gb+ZnI8z6CFNCB+DyMp/BcjMfuZJB9QZ15ZNNXjHirj8M12j+tuycmbZt3HdirsVf//S7Niq SeYm3t1/1z/xHNdrzsG7Exy6+yMxtJzLZNgn5jpXSrZ/5Z/1qc2kWgsD03+8bGaxThMpZoqN agnAUhviAd+mIQWyo7dcLW1x/wAkYVaI74qp7DAzCi1SaYUFSmICEdqYQlKbFDJf20f880a0 +brlwYPcU8f9b9WVS5Mwrj7A+WaX+JyOjPYzWND4gfqzog4SVeZD/ocY8ZB+psxNZ9Dbi5vO fOnw6fav/LdRn7ic1uD63Y4Buf6in+ZMVfLEjfyyxN/w1P45uIusLyvTf96aYz5IDLoUNBmK WSNngqqNTpQHJ0wUimRpK1kwoU2jFPfFC0pUbYpaEdDU/RikLZem+AMgEE6bFjliWMyDlM6j qWIH0mmXhreweYx6PlJ06fDAn/DJ/TKcnJzdGP3gRuhrx0a0H/FQzTnmWzJ9Rekaca2Fsf8A ipP+IjN/j+ke510uaV+bGIsoV8ZRX6FbMbWfR8WePm8q8/7aXan/AIvP/Jt8q7O/vD/VTl5K /nUer5Wu2HYwSf8AJRP+a8yxzYPMdP8A96Powz5KE9QVFMpZKyigqcUK0CcjU98ULro0PEHE MUOHAwqro/JN8BSFlOJJAriqxyTXbFKC1A0tXHtk4pLvI8fqeZ7L/I9R/wDgY3y08mLLdeb1 POekR/yLF+LTyYMm2CSR9QZ75damsW/vzH/Ctmr0n1huycmcZuHHdirsVf/T7NiqQ+Yj+9gF f2W2+kZrdf0bsSQXf92p+eY2k5ts+TC/P8fPQGan93NG30Gq/wAc2kebjl51p398w9sM+SxT pMpZo23oVYd8iUho4hS0fHJNTVTirRrhVTb9WBkpgVJOFAQ9yQI23phDNCeWovW1/T0/4vRv +A/ef8a5d0ans0dd/Dif4DKZ8m0Ik7L9GaXq5DO4DWCM+KL+rOjjycEpT5l/3nhH+Wf1Zh63 6W3FzefedkJ0UN/JMh/HNbhPqdlpfq/zVbz1D63k25frSOOT7irZuIusk8f0wf6WBhnyYhmk KUpmMlMJFBjGTQhXXfIqtIwsVpAxVaRgVYwpiUqLippgCULcfCpyYZscsYvX1KCMb+pOi/e4 zIYPWfOziPy+Y/55o1H0Vf8A40zHycnP0I/efBM9NThplqvhCn/ERmp6rPmXoGl/8c21/wCM a/qzfYvoH9VwJc0q82n/AEe3Hi5P3DMbW/SGWPm8w8/pXRYD4XAH3pIMq7O/vP8ANZZfpV9d Uz+Ub0dT9TST/gPSl/40zN6tfR5fYbXH0Yz5KE+iWoyhKtQlgvbvigohfhNcCFC5NWrkghD0 woV46qv44CkBeNxgZBbIKLilLNRalu/yyyKo78uk5eYGf/fdvIf+CKJ/xtlkuSAyG+Bk8/2i /wAgjJ/2MDS/8bYM+2nKx+tnug/8di2+bf8AEWzV6X6w3T5M6zcuO7FXYq//1OzYqx/zEf8A SIf9Q/rzWa/o34kjuhWEfOmYulPqbJ8mKebYTP5evlHUIJB/sGDZtYtBeX6ef9I+YyU+SAna ZSzRELcTgKAqN1wBJWk7ZJrdXCrsVWEYE2sApXFIQV59hvkTk4pKp5Gi9TzJbH/fayP9yFf+ NstPJg9aj/a9gB95OY+Q+lsHNEv0OaZyGc23+88X+ov6s6SPJwilXmX+5g/1z+rMPW/SGzFz YP5ui9TQLmnVOLj6GGarGfU7LSn1hE6lEb/yJIVFWksaj5hP7M3UXXZRUiHiWmn/AExD45Of JrDO4o9hmNSo8LWLJIQrrvkVWMuFCmRiq2hxVY6nvgKVJl64EhA3R+FqeBycWdpX5StzceZN PSm3rBz8kBf+GZB5Nb0D8wpT9Rs4Ad5JWen+qvD/AJm5jZeTtNAN5H+iyaJOECJ/Kir9wGak NJ5s40r/AI5tr/xjX9Wb/F9A/quFLmlHm4/u7Uf5T/qXMXW/SGWN5z54j5aAT/vueJvv5J/x vlHZ5rKGeUelE2iC+8uRp2ubAx/SYTF/xNc2EtpFqHJ5JYn9+vuMZckMjhFAMxyzVox8bHww sV53rgClTYVG+SQsEYxtDZxS2nUjAkOk+ziElKtQTlbua0AoMtigp9+WdtW41C6I2WOOFT7u xkP/ACbyUlCZWjfWfzCuX6rD64H/ADzjFtg1m2ABcf1s+0I01e1+bf8AEWzWaX6w35OTOs3L jOxV2Kv/1ezYqx/zF/vRD/qH9eazX9G/Eklx/dH2IOYWnPrbZckkvYRPa3EB6SRun3gjNuGh 45ZgpchT13B+jLJcmI5p9GdgcobFQe2LBV5Vp+OBJOzmG2Fg4DYYqu44q7jiqxlxZBLb8AQy H22rk4oTn8trQvfXl2RtDEsQP+VI3I/8LHlkkB6REvw18XA+4ZjZjUS2x5qz9DmoDezq3/3n i/1F/VnSR5OCUp8yf3EH+uf1Zh636G3FzYnrcXq6VcxdeUTU+gVzUDm52E1MIvymn13ydbxt uRHJC3+xLL+rN1jPpDj6uPDlkHhUcJttUaE7GKV4/wDgWK5bLk4zPYUPpr8hmOhFwiqEYVUJ ExVSZaYoUyMCrCtMVWMMUqLjY5EpCX3bCOGZ/BDT5nLIpVPy2tPW157g9LaFj9LkIMuPJAT/ AM6fv9c0y0BrstR/ryf82ZiZzTttGKxyLMn6N92awOMzTSxTTrXv+6X9Wb/H9I/quFLmk3m6 tbTw+P8A40zD13IM8bA/Nyc9Aux/KEf/AIGRcxtEayxZ5B6Vnk6X1dCta/7peSI/IOX/AOIy Zt8wqZaI8nl9xbNY6xPaN1gmki+hWZR+GRPJKdwVIBzHKhFxKRy+eAqu40rigqbDChaBirVM UuUdcSkLJTRcQqUanIRDx/mbLooZz+XFsYdEa4YbXFwzj/VjCx/rWTDJIQfkstc63f3j/aMT MT/lTSh/4ZDtI1CITh5l6LogrrFqPcn7lbNdpf7wN0+TOs3LjOxV2Kv/1uzYqkHmP++tz/kt +sZrdf0bsSRy7xsPbNdiNSDeeSVyfDIfnX783IccvJNatDYeYLmDoolLL/qv8a/ry3mGPVFx uKdcppmSrKw8caYKisPHBS2v5JTrjSGw6eOFDfJPHAlvmg7jGkLWkipuRXxrjSQlOqyD0SBQ 1IFRlsElm/5eWRg0BrhtjdzM4/1E/dL/AMMr4ZKGYRj4Iz41Y/TvmJqT6W2Db/ZzWDm3M8iF IkHgo/VnRjk4KVeZB/osR8JKfeDmHrfobcXNjV0A0JU9GBB+kUzUOVE0Vv5aS106+sW+1a3F QP8AJkFf+JK2bfTm4s+0R6xL+fF5V51046Z5yvYyKJLL68fyk3b/AIblmR0dcnlvfWwgQNIA QACPDKaVExXtvvSRfvxQte7tz/uxfvwJU2uIezr9+LFS9aKn2x94xVY08X84+/AlTaeL+Yfe MUqUk8VD8Y+/GkhJdWuV+qyKrAlqCnzOWQCsu/K+wMem3V8w3uJBGh/yYuv/AA7ZORUKcr/X /PqjqkD8R8oU/wCqmYGoOxd3EcOD+szVz8JzCDgM6sRSytx0pGn/ABEZ0EPpDhHmkXm3/j08 Kv8A8a5ha7kGzGw3XIvX0y7h7vDIB8wvJf8AiOYOA1MH+k2S5JP+X04lsby0P2opEmUf5Mq8 G/4aHOg1I3BcXGWJ+fLNrPzRJMfsXSpcKfenpSf8lI8oHJmoW19EAo5D78qMVTBL2I1I707j IGKhv62lcRFBU2uk98lwoW/WY/fHhVo3Se+NLbvrMe3Xxxpkoy3KU74QFSfUpQ/ELvSpplkU PU+P6E8p8AOMltZhAD19aUcP+T83LDAXIJOwSnyDDRL+emzNHEv+wDO3/E1zG7Ul6gGWDk9A 0AA6zbV/yv8AiDZiaX+8DZk5M4zcOO7FXYq//9fs2KpD5kX4rZv9cf8AEc12vGwbsSRNuSPH NUDu5CWzqeSnxqv0jfN1A7OOWAfmFprJcW2ooNpB6UhH8y7p/wALl8WBYklzcDYMflTDwotE NJqUSB5I3RD9l3RlU/JmAXEwpF2pnUbkeGDhCWv0lcHsDjwocdRuP5R+OPCrX6RnPYY8Cu+v XR8AMPCFa+uXB/aH0A48IVaFubmRY0BeR2CRrTqzHioxpL2yysRp+m2unpuYI0hqO7Uozf8A BcmyBSEyIANB0AoMwNWdm6AWHfYdzmFHmGws+UUUDwGdG4SVeYh/oKHwkH6mzE1g9DZj5sXu T+6zUBygg/JU4tfNV3anZL2JuA7F4j6v/EJWzP0kujk6wcWKMv5vpSj84tCke5stUt0qxBhl p/wSZnB1LzBmu4tizL9+T4UW2t5eJWkh365ExCbWtqN2Du/4Y8IVx1O58Qfox4VWnU7j2x4Q hadSuPbHhS19fuz0pjwhC1ry5PVwMeFNqZeWUheXNmICqO5Oww0r27SbOPQ/L0ED7C1hLzH/ ACqepJ/w2VyLZCNkBiXk4PdazdX0m7BWJP8AlStXNZnLu9V6YCLOHNVyh1r0CEcYkXwUD8M6 AcnBSHzYP3dqf8ph+AzC1v0htxsTugOjfZqOXyPwnNbFtYd5JlWy8zfVHNFuBLa+xdTzi/4a LjnT5RxYoycKO0iEw/NLSWk0+2v46BrVyj12JSUDp/NSRE+H/LzDiW15rFbNL/uyFD0pKeH/ AAzLw/4bJoVJtPvbdPUlhPoncTRsHjI/4yxGSP8A4bFUNU/suR8zTBSrubj/AHaR9Jw0ENGW Q9Jj9JIxpWi8veQ0+df1Y0rRk/ymb6aY0lbzr2r8yTiqdeUdM/Sev2sTx1t4W9e48OEfxUb/ AF34R4CrOfPV4EsIbWv7y4l9Rh/kRDv/AK0ki/8AAZbpo3K/5qJnZU8mxelokbEUMzyS/QW9 Nf8AiGanXSvKW7FtFmflwV1iH2Vv+InI6T62WTkzbNs47sVdir//0OzYqkvmRf3MDeDkV+Y/ szB1w9A97bi5sdf7WadyUNPGSjEDdTyA+XX/AIXNvgNxDRPmhPOWkB9KmisZfUZoRIrrtU9W QU/mGZJa3kVrdarb8vqkkqBTycRswoRtyZfi6ZNimV7578zahpy6Xe3pns1p8EiJyPH7NZUV Xan+VhtDHnoSSu1e39MUqZZ+laYFa5v4n78Ku5udu+Kq8dtKfiKn7icCriHBK8WLAcj2oB32 xQyn8vNJ+v6wbuRCYLACUMSePqHaJP8AW/3Z/sMiSyD1FV5XA8Ixyb5n4VyDJc2xOazUyuTf Dk1CvOaJP5nUfeRlOIXMe9MuTPc6Fw0s18E6ax/lZT+NMxtUP3ZZ4+bFLgVizTxctJyJLS5j 1lK00yWOeYDr6O8Vx/yRLZl6Y0XKB4sZgzLzhZTajoFyLFgbj0/VtXFDUgcl4/6y/ZzYl1Dx K11bzZZWReynNxY7l45I45wp/b5pPHJxyVqll3rsd8wN7YW6yVHKa2T6s5HeqxH6sf8AkRht UPNaQyQtcWUwljXd4XokyDxaP7Mi/wDFkLP/ALDFCAMhHTbFKz1H8cVa5mvTf5YquEUrbtUD 3wK1wUGlGY+GFWT+QdITUNdSSWMtBaD1mJ6cgf3df9lkSUs9863/ANX0loFP7y7b0wP8kfFI f+B+HMfIaDn6HHxZL/mJd5Kg9KxkmPWaQkf6qDjmtyblytZK5MqiHKSJe7OB95wQHqDgnk9B zfuEkPmsf6Nbt4SEfeP7Mwtb9IbMfNiF6PhPuM1sW0vP9WSSy1uWaHaRZEuoSP5vhm/5Ohs6 fRfvMFOFk2m9O1nT7bzN5bb6uQUvYVmtmPRXpzSv+q37t8wSKLc8Vh0S7m9dI6pc2zFZI22o VPFkP8rcvs/sZMMSaQUct5Z3BaNmhnQ0JWqsCNirf80tioXzT29yjGSH07zqHhUBH9pYRRYn /wCLIfg/4pwpQvoyHegX5nFDRhkA6V+RxVqKMyPwrxbwO2Kos6fcInP0qr/Md8FpWTQTQqvq twkf4hF0ISlQ8n8nP/da4SGINvTvI2jSafowuZwRc31H4nqsQ/uVof56+q2VyLMMa823/wBd 1aUR7x29LeL3Kk+o3+ymZ8z8MeGFtUzZZrpsC21rFbL0hRI/+BHxf8NnNZZcUiXMjsGT+V0L aqWHRI2J+mi5kaIeoscnJmWbRodirsVf/9Hs2KpT5iWtkh8JB+psw9aP3bZj5sZfrmlclpBU 5stGdiGrIvjhrE0R39I0H+q26f8ANOZrS8z826NcaJqJ1G0FLS5J5ilVVj9pWH8rZIFBFsRu 3t2YPEhRm+3H1UH/AIrP2qZPZiL6ut7C5uTVI2em5A2Uf679MBLJGW+m24lpd3sFpEN2KgzP /qpHF9pv9Z+ONrSrqFjpKwtLpmpC64CrwXERhkP/ABj+1HJ/qcueBUnoOQIrG43BHTCqY2Wr 3MZEMjUrtWlajAYrapL6t9dJp+nRM5mcKB/uyaQn4OdPsov7Mf2I/t5K2IHUvX9D0GHy/pEd iGDyisl1MBTlI32/9gn2E/yMqJbAjoUIi5n7Up5fIfsj/gcjJIU375p8hsuQFXTlDahag/78 U7exrk9MLyBE/pZxm+cRA6yK6ZP7AH7mBynOPQWUObD5d4s0kXMX+XzEdT+rTKGhuo3idDuC COXE/c2ZWmPqr+ciZoWE78vtKljNpFxX6zpL/VwT+3BTlZzf7O34o3/FsUubPo4+Tnf895r5 rsrny1q8t9aLXTNQJ9WMD4UlP2vl6n2sAay881SS1kn9SFShYnnH2B/4rP8AK2T2Yi+qhDZX FwapGzkbhVGw+bYLZI210kPIfrVzBZRLQu8h5tv2SKPk7tja0v1HSrCOJp9N1GG/jQVlidDB KB/MiSf3q/6nx42qTgDkCvwONx3GKE1s9XIHoTRpy8SBvgpNrLpo5JxaWCF3kYK0gHxSE/Zj Rf2EyVgcmABuy9X8raCuh6UsDUN3N+8uWH8xH2P9WPKyW0BiPmzUfr2qOqNygth6UYHQt/ux v+C+D/YZh5ZWXfaPHwQv+KbKNIg+q2UEB6oihv8AWPxNmCd93ByyuRKeaevO/tE8ZU/A5ZgF 5A0T5M9zeOGknmkVsoj4Sj/iLZh6z6P85sx82IXa1XNZBskwvzPCFuracf7sRoz842qp/wCB kzoOyZbSi4uoHIsp/L3zBZixbRb2eOGaFy1l6jBPUjk+N40L8V5wy8vh/kkyzV4qlY+mSMcr Cj5w0Cewvj5gsYz6TqU1GJRUMhFPrNB9rj/u3/IzEDY8suRcXt66K3qMp4mTboNl+Pv/AK+T vvQBSr+jraJaTXaoe6QgyMf9Z/hT/h8bVXs7zTrDk8Nil1OWqst4PUCgdFSAFY/9m/PAlS1O 7tb/AIyJZx2V0D8b29UjcH+aBi6pJ/lxt/sMKpayNSjio7MOow2hHabqUkD+jKeYIJiLbioG 3XB5qU78m+WJtd1A392C2nQyFpnbf1pQeXoj+Zf9/f8AAYCUgPQvMWo/ozTZbgELMfgt1P8A O2y0X/iv7f8AsMOKHHKlJoPNtJtfrmrW0TfEgf1ZSe6x/vGr/rcczdZLgxlqxiy9Dtd/1n5n OXk5oZT5RWt3ctTogFfmf7MzNCObDKyvNk0uxV2Kv//S7NiqW68pbTmI/ZZSfvp/HMbVC8ZZ w5sWcjY9s0blLoULGtNs2ekxkblpySbv47hYPWtmZJIiDIFUMXjBrJGFb9rj9jM4hqQ17p0u oWRVxDd2NwtQTyjND0+JfWXl/sUyCaea3X5beZ47h5LaO2miqfSHrjkFr8NfUWP4snaKSnWd C8xaVHG2qwiKKRuEYEyPU/5MaMTt/q47IS30l8cKuMa+OBW7e2nuruGztYzLcznjFGCq1Phy cquFDIP+Vb+b5PhawWFgdjJNEtD9DtgtLNfJnlW48vpJd3kEEmrvVEm9YskcZ7RqkTfvH/3Y +AlICeepd3WoLbmVDFEvqXoSMhaH+5gWR2Y85Ptv8P8Adf6+RZFMJBUHISFhIQTsKU75qJxo t4KK0YV1W29iT9ytl2kH7wMcn0s0zduKhtSXlYXI/wCK2P3CuQyD0n3JjzYTIf3RzQjm5qJ8 tWUtzqKXfArbwVYORszEcQE/mzN0+P1WwySoUjPOEV/YGHzFpsrxyWvGLUY0QSepZlqu3pt1 e1ZvVX/iv1szyerVj39KE1W2vNQtGSeO2vrC6SqyRlo+SsKqyn98mBg8nvvy/wDM8N5JLbWa TW/I+iPWRmC1+Hly4fFkrY0ler2HmXT44zqdtJbQO3BPiXhyp04xt4Y0FSwovc4oWlVxS3FB Nc3EdtbxNPcTGkUUY5Mx8FGFUyHk/wA0S7LpVyGB+EsoWh/2TDG1Zl5L8rXemu19qVg/6QqR EGeMIi/ziju3Nv8AVyJSEz806/e6bHFDEYRc3PIcKszJHT+9r8K/a+FcqnKg5mlw+JL+iwe3 ZEnhaTeNXUv8ganMI7gu8yD00HolvIkhDoQVO4I8D0zH6OkIpO9DXnq1sPAk/cpOXaUfvA15 PpZvm5cRKPMqk6aWpsjqx9huv8cxtUPQzhzYJrGoR2lnJOylhGASF67kL3+eazDHjmIj+Jtk aFsHv7yS+mErDiiCkadaA7mv+U2ddpdMMMa/ik63Jk4iss7g2d7b3ywpcNbPz9CUAo6kFJI2 r/vyNmXLc+LjjSISovTF0Py7f6Yur6TLNaWkycnNrPJAV7SRyRRN6PqRt+7kX0s0cgQaLmWK ti7flf5clBa2vbuIHrR0cD51jVseJESDyYRr+l2Gkas9nY3ct4tv8F00yhQJOvpx8T8fFT8b ZK0pf6+2wGKFjS17YqjtA0+31bV4tOur36gtzRLeb0/VVpSaJE/xJ6fP9l8VZnL+VenQb32r SKAeojjjFfZmdsgZgc2yMDI7DiZBa6XZ22nRQLqdy+n2sfEFZI4YwifaLtaxxOf8tvV54BIH cJMDE0fS861S5tbzUp7q1iMNs1EgRixYom3qv6jO3qTH943+wzbabFwiz9UnEySsu0y9+oX0 dyV5IAySAdeDijcf8pftYNVh8SFBccqLP9Mu7e6hWeBw6Hao8R2zls0TE0XPjuzPyggpdSdy UX6PiOZmiGxa8rJcz2p2KuxV/9Ps2KqN3AtxbSQt+2pA+fVfxyE48QISDTz+Qv6kYY9HAI+n NFEVIOTeyeRRDiM30Rs4xVRHkqQgCX0qR3A56dKS0qf76Y9XX/itv2v995XKNMrVZ7SFbYXF lI8o25xN8Rox+0jDINe8f6Tzv8xtFufVh1cIzwxJ6NyvX0xWqSD+VDXi+Si2FiMOjxXS8re+ gQ0rwuG9M1/l5UK/7LG0IbUNMuLAUuJYDKTQQxSrM1D+03o80Rf9d8K07R9HvNb1GDTbReU8 zAlh0jQH45mP7Kx4bV7tqZ1L95bxc0SziQCchfUuGoBxSSSscXH7TvxkzFmZHk5mIQABl6uL /YJUv1mOcwwyvPdTqGWGVuSxL0aaWQf7r/5O/wC68ljgR1Y5colyEY/1E2tLVLSARIxc1LSS t9p3P2nb/P4csaFQ4EpPqztGyFDxJPbMDVNsU58pxNNePO5/uF2/1nqv/EeWT0UNyWGU7Muz aNC10WRGRt1YFSPY7YCLV5pqnqIk0XIgqWXw6VGaCcalTmwPJkHkm7J8uacp6qhXf/Jds2kD sz1EPUWSSTRmNgwqpFCD3B7ZYZOIIG2BQX6eWLw6bPU+Xrlj9Tdv+PZ33a2Zv2YTX9xJ+x9j Ixl0Lk5cJkOIfV/Gml5bRwQCe2maeMkB42FWFe4K5N1+8f6Tzf8AMnTrn17bUyWe1VPQmXtE 1eSSeyy14NkothYjBo1xdb2ssTimwdxGa/yfHtyw2hS1DS7/AE7iL2NYnb7MfqI70/m4xs9F w2q3SrG91DULe0suS3buDFIhIaOm5l5L9nhhV7ZeXl2C1vGC0ltGnrXBXkzsQB+7T4VZz9pv izFlI3QczHijQMv4kuvtV/Q1vJc39x65kH+jW9Ars1Ps/D/w2IsbksuEZCIwjwvPr2+ub+6k vLpuU0nYdFUfZjX/ACVyiUrLusOIY40FCuRZlkXlWeceuOZMacQqHoCa1pmPmDr9YACHpHlB HmvpJm6Qp1932/VyzJ0MdyXV5TszLNo46Hv4vWsriKlecbAD3ptkJi4kJDynzKtdIuh/xXX7 mU5q9Jtmj/Wbp/SWGquw+WdqHUldTFCceWfMt35dumZFM+nXBrd2gpWuy/WIeX+7eA+OP7E6 ZhanT8e4+tvx5K2L1KI6Z5ght9Q0yeMqSVd1BHNQKeky/CUkj/kkXmmaoitjzcjh3sPOvzA8 m3sd02r2UJmbiFvrdVqzhR8FxGv7bqnwSp/s8ALMsMtG8qyW7m5S4WUkGkLAEEfa4M3Jf+ec sX/PTDuhK75rEuPqcbwQLWrTSCR3/wApuKxxp/qouFWffln5Gurm8i13UYGitIPjso5BRnft cMp/3XH/ALq/nfASrL76xW1X63qN3E1xC7yXM7KDGIR9iEer8MKL/kLmMMV7nm535ihURwxr 8Tefa9r8d8hsNNT0NIVqmgKtO3XkQd1g/wAn/dv7ebXS6QR3I/zXX5s5kdzxFIzmxcZogYCl mHlUf7i4vEvIf+G/szktfvmLsMX0vWvLNqtvpMTftzVkc/M/D/wuZumhwwDXM2U3zIYOxV2K v//U7NirsVefXgpcsTtSU/8AEs0U/r/znJHJPoVBQHN5Dk4xVeOTQ0VBFCK4FtLzYzWj+rp7 cVrU27Gi/wDPM/7r/wBX7GVmDO3SXdlc1gvk9GQgqyyAUYHr1+B1ytLEdV/KnTLx2m0u6Nmz 7+mR6kW/8q1V0/4PCJIpL7P8m5/UBvdWjWAH4hBEeZHs0rcV/wCBw8S0zTSdP8s+UbZorFQJ n/vbiQhpnP8AlP1/1UTIkpAdNNqOpOHUfV4Cf7yRfi4/8VQH/iU//It8aSiLWzgtIykINXPK SRjyd2/mkf8AaOKFU4slpwKkusbyRD3zA1XRsiyXycP3F1t+2u/0HMrR/SWrIyPM1rdirznX QGvLzt+8fb6Tmj1H1ly8fIK3kiblolvEaqFaQLvStHP2TmdDk5efmyyW3maPlWo+/LCC4gmL Yd5ghSZHjmAeM1DKelO9cqk52I0xvT9c1HQXEQLXWmj7MZNZYx4Rsftx/wDFb4xzVsWWXRie 8fTNk1vquh69AyI6OXUrLbyABqHqskL/ABZeDfJ1U8coGpBiOrfldG7mTSbr0Fbf0JgXQeyS L8ar/rc8nxNdJfa/lVqzyA3d7BFHX4mjDO5Htz4Lh4lpm2iaDofliBjB8Uzf3t1KQXPty2CJ /krkSUgJTrfnm0jLR2FLmfoCP7pT/lP+3/sMqlMBzMOklPn6YsGury6vbhrm7kMszdz0A/lR f2FzHlIl3OLFHGKCnXItjq4oZH5WFYrg+LqPwzGzcw6/WHcPV/JaKLK4cD4jLQt4gKKD6OWb HRD0Opy82SZmtSlcCtvKB1KN+rAeSvKvMlP0Rd/8Yj/DNTpv76P9Zvn9JYaqngDQmgFaAmn3 Z2ZkI8y6qieTgVbZWBPhXfJAg8kU3TFCI07U9Q0q5+s6fOYJT/eKN45Kdpoj8L/8TynLgjPm 2QyGLN9O/M+2eIRa5ZOHGxnth6iH/K9NiJo/+Sua3Jo5Dl63JjlBbu4Pyn11/WnltUnbdmYt ayV/y6+izf7LMYwkOkmywVttaflLojC4ia0kmXdWZzct/sQTL/xHAIyPQqs1X80bMRtHpNvJ Meiu49FPvb95/wADFl8NLOX9FickQwLVdY1HVnDX0vJAarAlViB/m4VPqN/lyc8z8WmjD+lJ ollJQBGZLBaRgVYSKbGuApZp5XX/AHF259nP/DvnIazfNJ2OP6Xsemcv0bacqA+iladPsjNn j+ke5pPNFZNDsVdir//V7NirsVYHrSCO+nUbgS1+88s0uYVkP9ZyI8kylqVt+UjRwM/GVkPE 7j4PiH7PLNqL4WnqqyabfIQ1reSHkKhXCyqaf7FX/wCSuPEVUTd3tuQt3b8k7ywVNP8AWhb9 5/wHqZMTRwoqGeG4jEkDiRD+0p7+BydoanWIxt6wX0wKtzpxp/lctsBChKvT0enO3VyPG2Ev H/kl+7yo0z3WlbFtpFuuP/Fnr0/DBsu6vZRaYtWsli5D7TJTn/syf3n/AAWKEUcUoR7xOTR2 6NczKeLJFSin/i2VqRR/7JueBKyQX5oWeOAdwimRv+Dk9NP+SOBUOrSieNRNJJyajB+NONCW +FETFUFq5rcwj3zA1PMNseTLPKMZWwlkqDzlO3ccQBvmZpB6GrJzT/MtrdirzvzInC/vFBrV y3/BDl/HNLqR6y5OPkx3Q7e2vI9Ngvmc2bPcxIgYqgnqskdStPiaL1OGZmIWHN1MpR5Mgfy2 9q4Om39zayEFlAcuhA/yTlvCHDGol19aW37eYoEK3qjUIevrRjjIP9Zf+bcgYFyMeohe48Nj 91cwyAspIr+yRQ5jSdriNjb1JLcqrvWlXr8JH2q+1N8EbHJyJCNerkmFnN5rC0sp7r0x0Bq4 /wCHD5eDN1mQaa/+IVri887olZZ51Xx4Kv48BkiZtUY6YpDeS307cr2SWU9vUYkfQPs5UZS6 udix4ucOFQrTIN6MstKv71qW8LMPEA5OMCXGy6mEOZT618j3TANdTpFX9kfE3/C/815aMThT 15P0h2seVbTT9MkuxckPGVA5LRW5MF49WPfGWMAIw6ucpAFT8rf3EvvKPwXNdm5hs1Z9Qev+ UYjHpAc/7tkZh8h8H/GmbTSRqDqsnNPMymtogEEHceGKvJ/MwH6LvKCg9NqDwzU4P76P9dul 9KX+RdYttJ1it4wS0vYRA8p2COG5wszfso1XRs6bWYzKII/hcHDLenouoaDpOqXMttc20Eyp EkqMwBk+NnTsA6f3fwOj5qhY5OSxPVvy5PJ30iYqyiptpqsh/wCMcp/eJ/svVzLx6ycefrap YQWEXVnd2crQ3ULQTISrI3iAG2I+Fvhblm0xZYzFhxpQMearpekajq87W+nw+tIg5SVYKqqd uTscjmzRx80wgZJ4fy/v1eOG4vIY5pPsRiOR6kAsQrH0gx4q2YR13cG4YPNSuPIOpRITDcwS kfslXir/ALL96MRru8L4LHL7Tr6wkMd5CYn8ahlNenF1qrfZzLx5oz5NcoGKhBbXN1MsFtE8 0zbLHGOTE+wyU8kYiyojbKNO8gTO5GrXX1Zo0EslrF9sIx4rynceluw4/ulkzX5Naf4W6OLv T6Pyv5dtmKpZRyyx0DGUmZgT05eoWX/hcxZZpy5ltEAGH+dG09b2G3tIo43gjKz+kqoKseSo wQD4kX/ieZmkBok8mvLXJNPK6j9F2wJoCu58Ku2c9qd80v6zlQ+l7PDGscMcabqihVPsBQZt gKDQqYVdirsVf//W7NirsVYP5gUjULkd+QI+kKc0+o/vC3x5JvDGktt6bryRhQjNtj3i0S5o V4NRtpUeFmmjjDBeLBXAcAHkG+F6cfhyJgeiRJb+kKPyuI5+Q6KYm/40VshSV1pCHvXvI4mh jZOLBgU5tWobg38v8+WQBQSrXsTOsbqiy+i4kMD/AGXA/Yav/BL/AJeGYUKGp6vYzxxRCMwS CRTIWb0mjUbkgMyLLy+x/JlRZAIGbVAzkgw8SdlVlNBU9KN8TU/z/YwJVrZBNcLdcSFUEK5F C1RSm/xMuSCCq3YZoCqgtUjmqnixWvxqrfssy4EoS+1G1rbJaRfVkt2LcTGy0qpXiEEZ59f9 +f8AIzAtIKFtRmfkTJKoqQGBjX4vFpQrNT/VxSj4Lcx1eQhpSKVHQD+Va4lCV6ma3sQ8ATmv 1PMNseTMvKqFdJBIpzkdh778f+Ncz9KPQ0z5p1mSwdirz3zMpXUrseJB+9Qc02q+suTj5JJ5 fW0m0KSC8PCBpnBmqFaN1blHNC5+xNC3xJmVjOzn5o2R/VRkWuahYTBrotdwRBo4tQsv3qOr U+K4tk5SwS/D8Xw8MuEw4ktMeY/0isnmfQ5G5veoG/keqEf7F6HDYafCmOhSPWLrQrxppIHB 4xsxkQbGQA+mvLu8jHjlWQghzdJDJGVgMf0fUYNN1SK6u4hPbfZlWlaAn7YyrFIAuw1mKU4b PRJ9V0u9hhOlStxZgWZGUhANzzT4ev2cy3nzEjmove3IY8lCxk0+10G/xHfFDFvNup6S8P1e LjLdE/E0YGw/ymGVZJCnYaPFLi4vpixrSXs0v4je/wC89fjNK098qhV7uw1PEYHhehyXVgEt zps0SxI3JuLqqlaft/F8WZToaKDk8w2lqxa8u4ioJpHEfUc1+z9jASAzjilLkGK6/wCYJtYk VFUxWURrHGT8TH/fkn/GmY8527TT6fg3P1Jh5V/3nf3lP4KMwc31Bq1X1PYvKqldEt69y5/4 ds22mH7sOrnzTjMhg7FXlfmyEx2GoRd0WQGnT4TmrxCs4/rt0vpYdZ2tzdusFtC1xKVLeki8 iVH2m4/y5185xiPUXViJJ2T3T9a82aDH6axym2Gwhu4XdFHgkuzon+Tz4ZgzxYZ8pcJcgTmO YTJfzS1UIV/Rtvz7lZXAr/q8Mr/Ik8pRT4w7mM61rd3rFz9YukjjapPCMGlSFXct8R+GNczc GAYw05MnEo6NrN/ouoJf2DATAFJI3qUkQ/sSAf8ACthzYRkH9JYT4WZN+ZVhdESX9rcQSBCg WIRyopYUeSNvhlV2X4f9TNZLS5O5yRkig5PPOjx0e1iuZSFI4SKqg1PLkxr/AHn/ABZgGkyH onxYsU1nW7rVphJMBGi/YiXcD3Zv2mzY4MAxj+k0TnxFvy9r9xoGpLfQxLOOJSSJzSoYUqrf svvg1GHjGyYSpP7zz/ZXMsly9hP6rqqFRJGqhVqftAcm+2395z/yMwPyk27xYpLcecL+WJ4r GJbRXoGdGMktAKfboqLt+1w5ZbDSAfUWJy9zH5CxJLVLGpYt1qeta75nbVtyad7Z55Ti9Szs YgKmQRrT/Wb+3ORy75j/AF3YR+l7J02GbdobxV2KuxV//9fs2KuxViHmRT+k2r0ZUI/Vmq1Y 9bdDkrurNYfCCwUqzopoWQbuu3+Tmxh9DUea549J4wtFKI2uGCxhXZOpA68h/NkbKXSieBgs V1yPUK3xqd6fa+Fv+HwiZRQXLelJFiuU9N3PFGBqjN/L4q3+tlgnaOFfNMkYBapLGiqoLMT/ ACqq/abCSqGuJ5UUGa39JGIVPXZVqx+yvEer8R/lyoyZUhzJNDUi0jr/AJDgH/h0j/4lgtNL ob+OZ/TKvFKan05BQkDrxYckb/Ytiil00yx8RRndzxjjQVZj1oowJQrXErXD25lS3eJQ8q1D snL7IdmKxIzf89cCVKWWDp9YLHb/AHZTr/xj4Yqtty5n+En01B9QElqk/Y+0WxVAaga36+y1 zX6j6m0cme6B/wAce1/1P4nNng+gNEuaY5axdirBvNYrqzg/yJ+rNTrB63IxcmG6fHbto8dz coJbSy1J3u42FVMMi+l6zr+0lvKyM/8AkZkYqpzs5PT+YyGfQfLrvCEtIfUnNIzD+6ah/bDR tH8OXcIcAZZDrJL7/wAtW8lYre8ljkXcJKfXTfb/AHZ+8/4fIHGC3w1c4/0mN6ppep2VFuED xfsTRGqV/wBU0ZMonjIdng1cJmvoklKRT3Eogt42lmb7MaCrGntkIxJcvJljAWUfH5N1qQB5 IUg5dBJIqk+1FLZeMcnWz1uM9ONubybraCvFWHgknL8CcJhJrjqsY/hSi8028sjS4iKD3FP1 5UYkOdj1EJ8lK1tLm7lENtG0sh6KoqcQCWWTLGAsshs/I88rH63PHCw3aJfjcA/zBfhX/gsu GPvddPW39ITiDyXokQo7TTN41CD/AIUZLgDjnVZO9JvNWkaVpkdr9UDpPKzckLcgUA+1v0+P jkJgAOTpcs5S3PpVvK3+8pP+W2a7L9S6k+t7bo6BNKs1VQo9JDQdKkcjm6xD0h1UuaNyxDsV eZ+b4+Nrqw8FmP62zWwFZx/XbT9LEPLmsPoupwagqerGqmK4iHVonpz4f5aMqSLnUajFxw83 X458Jes2t5aarJDd2E6y6cY39QpuS/w8fV/ag9P4vg/3Z/sM0hjWxcxB3vlrT9Vb/SrNSjbx XK7Nx41H71OEnLl/sclGco8igxB5vPvNfloaHOhimMttL9kPTmh3opI+3subTTakz2l9TjZc YG4Q/ljy3N5ivJraG4S3+roskhYcnKsSv7uOq8uPH42yzUajw+Q4kY8fEyVvy8sIbg2s73Uj CMSGXlHGhqeHFF4cnb+fj/d80zXnWZG8YopfceQrJ0P1G8ljICkLKqyJRhyT7IhfEa2Y5qcI Yvq+jXelSKlyyNzJCtGTQ0CnowDft5n4c4yBqnDhTDyp5Rn8xGaUTiC0tmVZXA5OSwJ4xr9l fs/abKtRqeDYDdMIWyTTtB8u28Kz/UvUkLUUzfv2Aojqzg/uUbjIv2U+D7Ga+eacuZbxABMP rtqikL/o8SKXYlRGiqO7Uoq5VzZ0828yapHqepy3MQ/dKqxRsRQsqV+Nv9av/AZtcGMxhu48 5WWaeSlIOlBevKLf7jnNjfMf67l/wvW82rS7FXYq7FX/0OzYq7FWLea1VbmFxXkyEHw2O3/E s12sG4bcarZvSAEmgpWp+WZ2L6WqfNCzQ2bsWguUheoYpVWjLA8lbhX7XL+XCYhItSittQQE Rm2mDNy5FmrUbCg4tx45HgKbRUdtcM6SXboxQ8kjQEjl/MWan/EcIgi1SeNnKSRuY5om5xP1 AbpuO/JTxwyChC3+oanNHGssJVonDCWEczsd+HxLx9Rfgfmj/BlZtlsgVmunfkYpmP8AKU4q CQAeJfj/AC4FRNvDIHEswCuKhEG9K9STipXyCQSJNC/CaPlxJFQQw4srD3xVAyw3TzNObeJp WqS4kYCpCqzcCv2mWNP+AwJURYFzWZoo960jqzb9fifiv/JPFUdGkcacY/s9Sa1JPizd2xKU mvTW/Psg/Xmu1H1Ng5PRdLjWPTbVFNQIkoT7gHNtjFRDjnmi8mh2KsK84KF1NGB3aJSR8iwz WaweoN+JiHl++tbPTbt7qRUgW6kDB9weQAKlf21f+XJ4+TssgJIr+ah5NXsrNv8AcRfxSWoP JbC9EiiM+Frc8P7v+RJPsZaJlplgEufpl/RXx+bwqVksw7A15xzJIK/eGx8UMPyUjyKDvvN0 tzxAtlSMHkQ55E0/Z+HplcsrkYtCQbkUk07VrnS9RTUIAHdSecbdGVjVlyEJ0XM1GDxI0y6f zjo+pG3kaRbSaI8iJFKkV+0vw1ibkvw5kiQLpZ6eceYb/wAQ6RES8l/G43PFak7hdtvlhJDE Y5HoxzzH5mi1BVtrRP3I+1K43PsqnKpzt2Gm0xieKSX6Drb6PdGcRCVHHF1rQ08VORhKm7U4 PEGzIF80aA0slwwnSSXd041FaKOqnf7GW8YdedLk7kPc+brNB/oVu7v2aZuK/wDArVjgOQM4 aSR5seu7y4vbhrm6kMkz9T0AHZUX9lcplK3Y48YgKDJPK4/0P5uf15hZPrcHUn1PdLaMRW8U S0oiKop02FM3oFB1ZVcKuxV5x53p6er0FP3b/ima/wD5ED+s2/wsB0qwu9SuEs7KMSXDKXCk hRxUfEeTZ1WTLGAsutETIpzF5T81Wchltka2lP2ngnVCafzcWXl/ssw56jDPmG6MJjk1d6j5 8sUpc3d4kY/bIR1/5GIj5GOPBLkUmcx0SG6vry7bndXElw3ZpGLU+XYZnY8UYD0holMnmts7 67sbpLyyma3uo68JU60P2lauzI37SNjkxRmKKYSMWS/8rK1jZru1guJFFPVV3iNKgmifvY15 cfi45r5aE9C5AzDuQ0v5gX7R0tbKC3DACvJpNh9mi0jwR0J6lTmDG72+u72cz3cpllPc9h/K q/srmdjxiAoNMpElfp2s6ppUjS6fdPbF6CQLQo1OnqI3wtkMuCM+bKMyE5j84+bbwFLdRMe7 RW5bc9/gqmYktNjHOTaMhPRBX1t5w1Af6bBdypWojKcUr/xiXiuTx+DDkUHiKRXEcsLPFMjR yps6OCrA/wCUpzJMgRYa6ovUvIESNcaashI4x8lA7sEqBnLYheY/1pOcfpeo5tGl2KuxV2Kv /9Hs2KuxVjfm5DS2k7fGp8d+JzA1o2BbMaFjjM9iYwaFgCp7VFGFcysQuLGXNVN/aSQCF4jF ellQKADQsacmB29Jfts2RpVKaSwenCIsDsrU4kkeFB7YpUjcSworxMxHIIYZDyJ+LieLn4v9 XJCRQi5pmRo41ALyuI05HioJ7u3hk5FAU9SiubBI3uJuQkbgqwhRuf8AjJyY5WSUhDSOy7rc 036ngwqP9iuC0rY7qUyrFIoblWjrt0FfiU1/4liqp8ctwIFlWEcS7MRVm348Iq/Dy/nZsVQH qkSz/WIGkEbBVNTJ1Lf5Xpt8C+o/BPg9T0/t4EqT36+p6axFSDvsoABNOVR+ztiqtagtI05+ yV4J771Lf804lUvuqtfSAbnioAHWpzXZ/rbRyemWycLeJCKFUUH6Bm4HJxlXCrsVYb51QreW 8tPhaIqD7qxP/G+a3WjcFuxvPtMZjbXKxqHnt74XVspp8Tx7NBv/AL+id1j/AOLeGSxGg7LN GwP6rLI9St760SW0ko7sFoy8uJ/bWZftRsn7WZLqzEg0UJdwaXd0Wazjm5fZbgoJqK/C68Wx pIkRyKQat5ZsktfrViXgIpWF25LueOxb4lymeMObh1cwaPrix3TtNudSvhYwMiSmpLOdgF+1 0+1lcIWXYZ84hG0+l8l2Vo0SahfS+pKaKIo1AJ9uZdsu8MOuOtmeXCun8kWDisF9JyPQyIrD /hCmPhhjHWTCQav5eu9KCu7pLC5oHSvX/KVumVyhTm4dVxmiN1Ty/oH6XaRnm9KGKnOgqxr2 UYwhaNTqDDYJ/aaP5cR3R7OR2jIBadmIJJPVY+Cfs8suEQHXSzzlzKYRWehVVIrGCpNADGCf +HwtfEe9i3mz9Fx38cFjEkcsSn6y0QAWpI4IQvw8lyrI7HRg8ymflRC1pEoFS8lAPGrZr5C8 jVqPqL3QAAADoM3rrW8Vdirzzz4gRdUoa84Cx9qpSn4ZgyFZ4/1mz+F5vpmoXWnXVvfWbcLi A8lr0YEcXjf/ACJF+HOnyYxONF18ZcJeoWHnLQdZWF5nS1uoAW+rzMEf1SOK8ZW/dSRAF2/4 DNLkwyhzDmRkDyTOe5syXYXsCxcKo5aMDkefw/8AJvKWTAPPVx5bmkibTHje8Un1mgoVZT2k dfh+H9nNjouO/wDa2jNVf0kF5K07Q9U1d7PWJTHyjBtE5cFkcH41Linxcfspl+qyTjXD6WGK IPNmtx5d0uyv2ghsbZrVUrX01Zy3Et9uSv8AkfvP7v8AY/vc1ZyS6lyREIG60Dy9dNw+ooGN fjjX0iKdfiiK+PHDHLMcipiCwPzHp9np2om3s5TJHxBZCeTI38jPm002SU4+px8kQDsyPyRZ eW7nSp3keI6+rSCNZ+LFRT9w8EMhCSf5X+XmHqpy4q/hbccRTJ+F9HAqkR8vjPHkTSrMYo6r xX4I+CSSZhNqTX+u2uno0l667A+nAm8rkGi/BXklV+L4/gycIGRoKTTzfU72W+up7uX+8mYs QOgFOKJ/sECrm1EBCFOMTZt63+XcLtcwuB8EVsOR8CwVVzndMLyEuXPk9FzYtTsVdirsVf/S 7NirsVY95uVvq9u4+wrsD8yNv+I5hawekNmNBWTqtsGY0AAJPtTMjCfSxnzblaCdQXtpJVp8 LcCDT/JZuDZMyiUAFCm2tf8Al6jHgGNP+NjkfSndVthpyOPTNZh0MpYv9Hq/8a5IV0QbVpkS VDHIOSnqMBVAz2t0wAM4lRahBMCSAftLzQjkrUyFMrUPqVzI1XaHryqAzGvjQlcFLaKhgWGp LF5DsXO30KO2KtTiBlHrAcRuGJpQ/wCS2KQhDDG/2Jbgr2pVh9BdGwK5YLZDV0kkPWsgZv8A hfs/8LiqusySV4GpXZgQQR9BxKUtozamOFS5dAtOtdumYE/7wM+j07Nu47sVdirEfO4YSWh3 4cXp4Vqua/W9G7E8wsrpLZb53BdPWI9MdSWoqhf8otkcfJ20uQ/qoyeHWZx6sWk3NvddruOR I5GH8twhPCan+X+8y6pdHGM8XU8X+ahZZfO0K7xz8B0b0kcj/kXyw3JiI4D1Sa81LUpW4Xk0 pcfsPVAD/qfDlUpSc7DjxD6fUhI554JkuIJDHPGeSSL1ByMZUW7JATFFPR5zlk9P6/aetJH0 kjcrXcH7B/1cvGQOtnoiORXN5xttmjsZOS/Z5OAP+Fw8YYDRy70n1XW77VHUzkJEm6Qr9kHx P8zZVKVudhwDH/WQ9pf3ljJ6tpM0T9DToR4Mp2bBEkMsuOMx6k5g83a1x4i3ilJ/aCMKn5Ic t4j3OBLBjH8Sjd69r06kFWt1b7XpoVJ/2bfFgJkzhjxDrxJNXc+Pfxr75UQ58SDyZ55EVzJp wQVYzqelf2sx4f3wdZqOZe1ZuXXuxV2KvPfP4C/pChrztiT7fDx/41zBn/fxbB9JeaaVZSaj e2thCypLctwR3NFBoW3p/q/DnT5MnBG3AEbNMuf8tLtVHq3sfxGgHpEgn/ZPmAdf/RbRh80H c/lrqMYrA8EpHZkMZ++kmGOsj1ik4j3pFqWi6rpYBvbZoYyeKyAhkJ60DLmZj1EJ7Dm0yxkJ axB+10rt8x4ZbIAjdiE4tdW83rGFtLm9eIdB6ZmUfTJG/wDxLMCeHDfPhcgTmh77WvMpHG+u 7mNT1Vl9Ef8ACpHhhgw9DxqZySkmu/Wu9fnmYAA0o2z0DV9RiE1rZvLCT8MpoqbbHi7lf+Fy jJmxjaTOMT0TVPJ/mYx8WmWNP5GuXI+5A65iHNi/mtvDLvQsvkvXI6lVhlJ68Jdz/wAjFTJx 1UB04UHHJj86vGXjcUdSVdfAqeLDL5yBjbACi9t/LyJxLKwqI0gRGHap+z/xFs53SfVIuZPk zvNg1OxV2KuxV//T7NirsVY75w/3lt/9c/8AEcwtb9IbMaXWNGtQrbgrQj2pl2D6US5qhv76 0t3gB5IVIjm48ivhyXCRSAoNq6FYA7x1VSJ/hALtTYrv8ORSoy3Iu0aGGMuWBAcAhVr+16n2 cIVXlYxxxB3YRgqs8qir8KfE6/TkigKeotpsPotaUm5n4mkBlJ+yBGDvxZ+X2/8AIyKVCaTT yQBwJJ4gBQDX/YgHFK2B29cJGxMQB9RSSwH8tGP2cUFWE4t5pXlj5q/H05QORSg3Qj9leXx8 sCUBb3UqwS/WZ0knZiUPYL+yvbCrkmLqB/eOT+yK/j9nBaomCMxqxb7bmrU6Cn2V+jFKFtj/ ALmIjWn7+P8AWuYBP70M+j0zNu47sVdirEPPJ/eWg/yX/Wua7Xcg3Ynj0skq3F4kbFayVqOx U80b/YsuQxmgHdCIlAWymz80RXln6MsqW2ocQCz/AGC38yN0+L+XMsSBdTlwSgf6Ka/W1LIw kT0+PxEHfl4g1yTSlmt6tpH1SWG4kSdmUhY1o7V/Z3/YyMiKbsWOROwYfo1rYXepx299KY7d waFTx5N+ynM/ZrlMACXZamc4w2ZfJpGg2csUMenwy8+rSlnY7hPh5k8m+Lk3+Rl9B1RySPMl fJo3l+YAfU4Ry+yYyUP0cGxoKJyHVjHmXR7DTTEbWRg0tawueRAH7VevH/WyqcQHO02WUjRR nlObRxA6SrF+kQxIMoG60+H0+fw/62ThVNOqEuL+iyKyuL82he5QRzVPGOPYcf2emTcTZVlv 4beH1buYRKBU8m/UMBLKMSeTz3WtQj1DUpbqJOETBUQEUJCj7bf5TZRM27bT4zAbs4/Lslbr TKd2P4hsxsP984Oo6vYc3DguxV2KvO/zAPx34/5dj/xA5gZD++j/AJrYPpeVRuVCMrFXSjIy mhDD4lZT4jOqIBFFwLos90v8yh6MUWswNJJCwZLiEAgkd3iPRv8AUzV5NHIfT6nIjlB5ptL+ Znl4GSVVmZ5ePJRE37IoKcqKMp/LZD0Zcce9ifmfzsdZgNnb23p2pIZnloXJH2eKr8Kf8FmX g0pieKTXPIKoKXkbWtF0rVJTrMIaGdFWK5py9JgT9ofspJX+8/yMlq4SluEYiHoLXenTXMlx azma2K/uwkishFE4qiKfhkV/VZ2bNWQ5CCvdQ06JWM8ghhA6zMoB9uJY4gJeY69d6ddak82n xiOAgAkLwDMPtSKn7PLNvpoyEfU42Qi9mR6Z54sG8vw6JqSPbGCNIUu4V5qyRmql1X40bj8M n8+YWXTSBseptjMJrN5n8ttaxRx6goWJQtTy5HiKVI48ueY/hy7mdhJtX88WoiaPSwXnOwnd eKL/AJSq3xO38uXY9MSd/TFicgHJg7ksak1JO5O5JPjmbk2i0x5vdfy+ryvPALEP+J5oNF/E 5eRmubBqdirsVdir/9Ts2KuxVj3m8Vt7fbbm2/0Zg676Q2Y+aT2c8aRBWahA74dPljw81nE2 illVvssD8syhK2FOPE70FflhVose+BVNnUbE7+GApQr2tuxLKjKT1KErXI0qz6lD3EhHgWP8 DgpKqgjjUIihFH7IFMVbJxVYyoeqg/MYparTYbDArRagwWlCWCk6rAx7zpT/AIJc14N5R/Wb Dyel5uXGdirsVYh52Aae1H+Q/wCJXNdrujdiePanHLZ6hcrKpUM5Kt2IPcZVA7O5xEGIQDOr 1IIOTblIhfDDaOANbDYD7sWVLWodjviEEXzR9vrmtW6BY53ZF+yJAHp9LfFlgyFxJaWB6L28 xa2RtIsf+Ukag/fvh8QoGkgEulmkmlaSZ2klb7TsanIE25EYADZYQD1wJIVY7q6jHGOeRV8A 7AfryXEWvwonoFju8h5OxdvFiSfxwWyEQOS0mgOBlb038vo6XWlE96kfSrZRg/vnVZ+r1zNw 4TsVdirz3zlAbm/vYK09SMRhvDlGBX8c1eolWW/5rdHk8vl0nVLdihtXkVducdGBp7V5Zvsf aOIjc8LhywyQYepI3DLsykUIPuDmfCYkLBaTEhdyyaFjOAKk0xJTSmZgfsgt8v7chxdyaWVY EkR0PiDQ/wDC5WYg/wALIGuq0sQQTHv41BP44gCPKKk31d6qk0Ox99snxhFNk4Cq0nIkpWFv HIEppuBJJ544oVLu7qAqivfMbPlAid2yA3e8+QRRr4e0f65M0uh6uVlZjmxaW8VdirsVf//V 7NirsVY95tr6Nse3Nq/dmDrvpDZjY4e1M1QLctDlGDDYjL8WUxKCLR4lBUN45uBJocST9o09 hgV1QOgpirRbFVpbAq0tgStJHyxVaWxSpvJTMfPk4QyiFFnJOa4zJ6tlKljVtRtAOpmj/wCJ DJYfrHvWXJ6Nm+cV2KuxViPnT/ei18OD/rGa7XdG7Ewi8dvVIIUjwIBzAAFOQCkes2NvNbtP FGI7iMVPAUDqPtVA/ayyEqNfwuThykGixot/ZmU51u/1vuxS7meg+Ee2KLWknFbdhW3Envv8 98C21Tw+7Ch1cUFHaVppv5iHbhBHvIw6/wCquV5J8PL6mnJk4QyKPS9IjIC2oYj9pyScxzKX e4hyyPVlnloAaxYhECgNQKOgHE5LTD94GjJyem5u3EdirsVYH5lVl1i45ftBSvy4rmp1O2Ru hyYxKtGPbEMWN+YoEJW7VQJFISZh+0rbIzf6j/D/ALPNh2dlMZ8P8MmrKLFpIXPQdc6C3FW0 Fan4j4nBXeri2G1aLYLStJwWq0kdxkSqzp0P0ZDlyZNFsFrTI9B063EC3sqCWWQVjVxVVFac qHqzZpdXnMpcI9MYuRCNBPIHIkAUKv8AqgD9Wa2VU2g7s98hg+pentSP7/jzK0XVcjMc2DU7 FXYq7FX/1uzYq7FUHqlgt/ZvATR/tRt4MOmVZcYnGkxNFgs8c9rKYbhDHIvY/rHjminAwNFy QbU2YEbHIgpXxzlBscz8eYgNZjaqLrxGXDUDuY8Df1lcn48UcBd9YTxw+NHvXhLRnTxx8WPe vCWjMvjg8aPenhWmdcBzxXhKwzjKzqAnhUixZq9vfMPLOzu2ANFh3OY5ZMh8saRK866hOpWJ P7gHYsx250/lXNlo8BB4i05JdGW5s2l2KuxVLNd0oalZGNdp4/jhJ8f5T/r5RnxccaZRlRec X1lIkhjmQxTLsVYUOaYxMTRcoG0uuLGb0+cZBZTsPHFmCkU2g2zkskjWrHqjLzSv+Sw+LjmQ Jnq5Ec5H9JCSeXr4bxPFOP8AJfif+BemTGQNo1EeqGfRtWTrauR/kgN/xHJcQZDNHvUmsL9f tW0o/wBg39MeIMvEj3rfql5/yzy/8A39MNhfEHeuFhft9m2lP+wb+mPEO9HiR7166RqrdLST 6RT/AIlg4h3sTlj3q8fl6/beVo4B3LuCf+BTlgOQMTnCe6XYpbxmKCsgryeSlORzHnKzbizl xFMYrZywLii5USwZv5P0iU3A1KQcIUBWEEbsWHHmP8gLmfo8JviLRll0ZlmyaHYq7FUj8x6L JfxrcW/+9MII4fzr141/mXMXUYeMWPqizjKmCXMDJIY5Y2ikHUMKH8c19mOxbCLSu707k3LZ 0YEOpFQQexGSxzFsTFKZ/L9iR8AlhP8AknkP+Bf/AJqzZw1mQdeJpOMIKTy+R9i6H+zQj/iJ bMgdoHrFicQQ76FeA0WWF/8AZFf+JLlg7Qj1EmPhKZ0XUuyo3ykX+uH89D+kvhFb+hdS/wB9 r/wa/wBcfz2PzR4RcND1E9RGvzkX+GA62H9JPhFUTy/dH7c8Kf7It/xFcrOuHQSZeErxeX7d WBmmecf77iQqD83b/mnKJ6yRGw4WQgGQ21pN6IooRQAAvSgGauc924RKOsLGSSYJGhlmbZUU VJyveRoMgKem+XtIOl2PpyEG4lPOYjoD2Qf6ubXBi4I01SlZTXL2LsVdirsVf//X7NirsVdi qlPbW9ynC4iWVewcA/dXIyiDzSCgB5c0cS+p6H+wLMV/4GuU/lsd3TLjLpfLmjyD/efgfFGZ f1HJHBA9EcRQcvlCxP8AdzzJTxKt/wAa5WdLHzTxlDt5N/33eED/ACo+3/BjIflB3p8RRHk+ 7rvdx07URv64Pyh70+I0PKF7T4rmMHfYKx77YPyh718RePJ1xx+K7QN/qEj7+Qw/lPNfEVI/ Jyinq3ZJ7hUA/FmbCNIO9HiK8Pk+wVqyzSyUP2ahR8thXJjSxRxlFS+WNHkTisTRnsyO1f8A hiy5KWlxnoomVS18v6Ta0KwCR67PL8Zr9Pw/8Lhhp4R5BBmSmVMvYt4q7FXYq7FUPdWNndqF uYUlA6chUj5HrkZQEuYSDSAj8r6JG5f6vyr+yzMyj/Yk5SNNjB5MuMuuPK2hzoy/VVQnoyEq f+af+FyRwQPRAmUrm/L7SXaqyyKPA8T/AMarlR0sWfilAzflwB/vPdj5MpX/AIizZA6TuKRm UD+XupAnjdx0H2ficV/4XI/lJd6fFU38g6wCAs0bA1qRIwp96YPysl8UOH5fasT8U8f/ACMf /mjD+Vl/RXxQqJ+XNyw/e3Edfm7frC4RpT3r4qPg/LqxUD1bgs3+QgX/AIkXyY0o6lj4pRb+ RtNC0gnljPvxYfdxXGWjiVGUomy8oaRbHlIrXLf8Wn4f+AXiP+CyUNLCP9JByEp4qqqhVAVQ KADYADMprbxV2KuxV2KqM9pa3ApPCkvYc1DfryJiDzW1OLTNOhBEVtEtetEH9MAxxHIJsqUu h6PNX1LKE16kIAfvWmA449y2UDL5M8vyCn1cofFXb/jYtkfAitoGT8vNFYkpJKngKqR/xDB4 A75JtQb8t9MJ+G4kA91U/wDNOR8DzW2j+W1h2un+lAf44+B5rbf/ACrfTQRS5eneqqfux8Dz W1dPy80dRvLKT4jgP+NMP5cd8l4kdbeTtCgbl6JlI6eoxI+5eOSGCIXiK+XyloUjhvQKU6qj sAfnvkTpoHonjKY2mnWNkCLWBIq9So3Pzb7WWxhGPIMSSUTk0OxV2KuxV2Kv/9k= --XX4D7D4C1C-01614D7DXX-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 05:54: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 FAA14219 for ; Wed, 4 Oct 2000 05:54:14 -0400 (EDT) Received: from standards (47.234.32.16:4678) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C004@standards.nortelnetworks.com>; Wed, 4 Oct 2000 5:37:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16605 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 05:37:52 -0400 Received: from mailhost.abrandnewworld.se (193.13.14.6:56017) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C003@standards.nortelnetworks.com>; Wed, 4 Oct 2000 5:27:51 -0400 Received: from nthele ([192.168.21.13]) by mailhost.abrandnewworld.se (8.8.8/8.8.5) with SMTP id LAA09516 for ; Wed, 4 Oct 2000 11:41:31 +0200 (CEST) Received: by localhost with Microsoft MAPI; Wed, 4 Oct 2000 11:42:09 +0200 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <01C02DF8.20B8DFA0.henrik.levkowetz@abrandnewworld.se> Date: Wed, 4 Oct 2000 11:42:07 +0200 Reply-To: "henrik@levkowetz.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Henrik Levkowetz Subject: Re: [MOBILE-IP] Comments on draft-calhoun-mobileip-proactive-fa-02.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit On Tuesday, October 03, 2000 20:12, Pete McCann [SMTP:mccap@RESEARCH.BELL-LABS.COM] wrote: > >> 11). I take objection to including section 9.0-9.2. All link layers should > >> be addressed > >> in generalities with maybe a distinction between fixed and wireless > >> being allowed. > >> Of course I am not a fan of the MIER approach at all. > > psc> Whether MIER is good or not, it is irrelevant. We have limited > psc> address space, and MIER allows us to conserve some space. What, > psc> exactly, would you prefer to see in sections 9.0-9.2? > > The link-layer address can be used as an opaque identifier, and > doesn't need to be understood by the FA, so the protocol is not > link-layer specific. We just need to maintain a type space to > keep the identifiers unique across different technologies. If > you have another technology in mind speak up and we can start to > fill in the type space. I agree. I'm concerned, however, that the octet sub-type may be insufficient. It may need to distinguish between not only different wireless transmission technologies, but also between the same technology applied in different frequency bands. -- An alternative is of course to express link-layer address formats in such a manner that it comprises both band and address information, when the technology itself doesn't have an address scheme that lets you derive the frequency band from the link layer address. Then the LLA field in 9.0 would actually be something more than a simple link layer address. Regards, Henrik From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 06:47: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 GAA14672 for ; Wed, 4 Oct 2000 06:47:19 -0400 (EDT) Received: from standards (47.234.32.16:3380) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C05F@standards.nortelnetworks.com>; Wed, 4 Oct 2000 6:31:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16706 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 06:31:04 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C050@standards.nortelnetworks.com>; Wed, 4 Oct 2000 6:21:03 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14559; Wed, 4 Oct 2000 06:35:29 -0400 (EDT) Message-ID: <200010041035.GAA14559@ietf.org> Date: Wed, 4 Oct 2000 06:35:29 -0400 Reply-To: iesg@ietf.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: The IESG Subject: [MOBILE-IP] Last Call: IP Mobility Support for IPv4, revised to Proposed Standard To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM The IESG has received a request from the IP Routing for Wireless/Mobile Hosts Working Group to consider IP Mobility Support for IPv4, revised as a Proposed Standard. The intent is for this document to replace RFC2002, currently a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by October 18, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc2002-bis-03.txt From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 08:34: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 IAA17494 for ; Wed, 4 Oct 2000 08:34:02 -0400 (EDT) Received: from standards (47.234.32.16:1321) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C219@standards.nortelnetworks.com>; Wed, 4 Oct 2000 8:16:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17278 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 08:16:59 -0400 Received: from esebh01nok.ntc.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C218@standards.nortelnetworks.com>; Wed, 4 Oct 2000 8:16:59 -0400 Received: by esebh01nok with Internet Mail Service (5.5.2650.10) id ; Wed, 4 Oct 2000 15:31:25 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <6D1A8E7871B9D211B3B00008C7490AA504E622E6@treis03nok> Date: Wed, 4 Oct 2000 15:31:05 +0300 Reply-To: henry.haverinen@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Henry Haverinen Subject: [MOBILE-IP] The use of existing authorization infrastructures with Mobile IP/ AAA To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi all, In summary, I propose the following additions to draft-calhoun-diameter-mobileip-10.txt in this mail. 1. Two new rules for FA behavior when receiving the AMA Command in response to the AMR Command: a) If the AMA Command doesn't contain a MIP-Reg-Reply AVP, the FA must forward the Reg.Request in question to the HA itself. b) If the AMA Command includes the Result-Code AVP set to an error, the FA sends the MN a Reg.Reply with an error code but nevertheless includes any AAA or key distribution extensions from the AMA Command. 2. One new rule for HA behaviour: If the HA receives a Registration Request that contains the MN-AAA Authentication extension, either relayed by a FA or directly from a MN that is registering a co-located care-of address, the HA may issue the AMR Command in order to authorize the Reg.Request. The AMR Command includes some new flag which tells the AAA server that it does not have to contact the home agent, and that the request came directly from the home agent. --- The draft draft-haverinen-mobileip-gsmsim-00.txt describes how the existing GSM authorization infrastructure can be leveraged to achieve mobile user authorization for Mobile IP. The idea is not to use the GSM radio access technology, but to show how GSM SIM authorization could be used for Mobile IP authorization over any link layer, for example on WLAN hot spots. I'm writing a new revision of the draft which will fix the issues discussed on this mailing list and make the protocol to use the Mobile IP AAA extensions, so that the mobility agents don't need to be GSM SIM aware. The general model of leveraging an existing large scale authorization/charging infrastructure is very important because building new authorization infrastructures from scratch is hard: getting the necessary contracts and agreements in place takes effort and time. GSM authorization infrastructure is just one example of an existing large scale authorization infrastructure. Another such global infrastructure is the credit-card infra: e.g., consider the following scenario: I travel to a new location, pay the local ISP using my credit card, and continue to use Mobile IP with an HA in my home ISP. In my opinion, any MIP/AAA proposal should be able to easily support use of existing authorization infrastructures because it will greatly speed up deployment of Mobile IP. However, the current MIP/AAA drafts (e.g., draft-calhoun-diameter-mobileip-10.txt) have a couple of assumptions that do not support such authorization. The important aspect is that when existing authorization infrastructures are used, HA and AAAH are not necessarily under the same administrative control, and are not co-located. They are probably not even close to each other. Let's use the term AAAH to denote the AAA server that can authorize the user, and probably charge/bill the user where necessary. In the GSM SIM case, the AAAH is the Authentication Centre (AuC) which resides deep inside the GSM network. The foreign domain may have a local AAA network which includes a AAA server that has an interface to the GSM network. In this case, the local AAA network is able to reach the AAAH but the AAA network isn't able to reach the home agent, as the current MIP/AAA drafts assume. Suppose that a FA issues the DIAMETER AA-Mobile-Node-Request (AMR) Command to authorize a Registration Request that uses GSM SIM. The current view is that the the response from AAA (AA-Mobile-Node-Answer, AMA Command) includes the Registration Reply from the HA in a MIP-Reg-Reply AVP, which isn't possible in this case. One way to support such authorization would be to add a new rule to the operation of the FA: if the response from the AAA doesn't contain the Registration Reply, the FA must forward the request to the HA itself. Besides the reachability of the HA through the AAA network, the GSM SIM authorization breaks another assumption. A mobile node that is using GSM SIM is not able to provide the visited domain with complete yet unforgeable credentials without ever having been in touch with its home domain, as required in draft-ietf-mobileip-aaa-reqs-04.txt. This is because GSM SIM requires true challenge/response authentication where AAAH generates the challenge. In other words, it takes two round trips to authorize the MN. The AAA response in the first round trip contains the challenge. The result code in the response indicates that the user was not authorized. True challenge/response could be supported by adding another new rule to the operation of the FA: if the AAA responds to the FA's authorization request with an error, the FA sends the MN a Reg.Reply with an error code but nevertheless includes any AAA or key distribution extensions from the AAA response. These extensions contain the challenge. The MN is now able to send another Reg.Request for which the authorization will be successful. The same approach can also be used to for authorization in the home domain. Both HA and FA can use the same AAAH (located elsewhere) for authorizing the mobile user. The HA may receive a Reg.Request (from a co-located MN or a FA) that contains the MN-AAA Authentication extension. The HA could then pass the request to the AAA network, for example with the DIAMETER AMR Command, and the AAA network would respond with the AMA command, using the AAAH on the GSM network. Here we probably need a new flag in the AAA request that tells the AAA server that it does not have to contact the home agent, and that the request came directly from the home agent. Regards, Henry P.S. I'd like to acknowledge that Asokan (n.asokan@nokia.com) has contributed a lot in these ideas and in this mail. Many thanks! From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 09:15: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 JAA18876 for ; Wed, 4 Oct 2000 09:15:03 -0400 (EDT) Received: from standards (47.234.32.16:1321) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C2BF@standards.nortelnetworks.com>; Wed, 4 Oct 2000 8:58:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17486 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 08:58:40 -0400 Received: from qhars002.nortel.com (47.101.112.102:37211) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C2BE@standards.nortelnetworks.com>; Wed, 4 Oct 2000 8:58:40 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Wed, 4 Oct 2000 14:11:02 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Wed, 4 Oct 2000 09:10:38 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 4 Oct 2000 09:10:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02E04.7921F7B0" Message-ID: Date: Wed, 4 Oct 2000 09:10:31 -0400 Reply-To: Muhammad Jaseemuddin Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Muhammad Jaseemuddin Subject: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt 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_01C02E04.7921F7B0 Content-Type: text/plain We have submitted a draft defining COPS usage for Mobile IP. The announcement is attached below. We will appreciate any comments. - Muhammad Jaseemuddin > -----Original Message----- > From: yaniv@iphighway.com [SMTP:yaniv@iphighway.com] > Sent: Wednesday, October 04, 2000 7:19 AM > To: rap@iphighway.com > Subject: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > To: IETF-Announce: ; > CC: rap@iphighway.com > From: Internet-Drafts@ietf.org > Reply-to: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > Date: Wed, 04 Oct 2000 06:54:46 -0400 > Sender: nsyracus@cnri.reston.va.us > > --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : COPS usage for Mobile IP (MIP) > Author(s) : M. Jaseemuddin, A. Lakas > Filename : draft-jaseem-rap-cops-mip-00.txt > Pages : 14 > Date : 03-Oct-00 > > Mobile IP is a protocol that is used to achieve transparent routing > of IP packets to a mobile node. A mobile node obtains a care-of- > address in the foreign network and registers that address with the > home agent. The home agent as well as the foreign agent can apply > policies to the mobile node registration. This draft defines COPS > [1] usage for Mobile IPv4 [2]. It describes how COPS is used to > control Mobile IP registration based on policies. It defines the > interactions between the PEP and the PDP to handle Mobile IP > registration messages. It also provides a guideline for mobility > agents on how to use this COPS client with regards to the > registration messages. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-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: <20001003122806.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-jaseem-rap-cops-mip-00.txt > > --OtherAccess > Content-Type: Message/External-body; > name="draft-jaseem-rap-cops-mip-00.txt"; > site="ftp.ietf.org"; > access-type="anon-ftp"; > directory="internet-drafts" > > > --OtherAccess-- > > --NextPart-- ------_=_NextPart_001_01C02E04.7921F7B0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt

We have submitted a = draft defining COPS usage for Mobile IP. The announcement is attached = below. We will appreciate any comments.

- Muhammad = Jaseemuddin

-----Original Message-----
From:   yaniv@iphighway.com = [SMTP:yaniv@iphighway.com]
Sent:   Wednesday, October 04, 2000 7:19 AM
To:     rap@iphighway.com
Subject:       = I-D = ACTION:draft-jaseem-rap-cops-mip-00.txt

To: IETF-Announce: ;
CC: rap@iphighway.com
From: Internet-Drafts@ietf.org
Reply-to: = Internet-Drafts@ietf.org
Subject: I-D = ACTION:draft-jaseem-rap-cops-mip-00.txt
Date: Wed, 04 Oct 2000 06:54:46 = -0400
Sender: = nsyracus@cnri.reston.va.us

--NextPart

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


        Title   =         : COPS usage for Mobile IP = (MIP)
        Author(s)       : M. = Jaseemuddin, A. Lakas
        Filename        : = draft-jaseem-rap-cops-mip-00.txt
        Pages   =         : 14
        Date    =         : 03-Oct-00
       =20
Mobile IP is a protocol that is used = to achieve transparent routing
of IP packets to a mobile node. A = mobile node obtains a care-of-
address in the foreign network and = registers that address with the
home agent. The home agent as well as = the foreign agent can apply
policies to the mobile node = registration. This draft defines COPS
[1] usage for Mobile IPv4 [2]. It = describes how COPS is used to
control Mobile IP registration based = on policies. It defines the
interactions between the PEP and the = PDP to handle Mobile IP
registration messages. It also = provides a guideline for mobility
agents on how to use this COPS client = with regards to the
registration messages.

A URL for this Internet-Draft = is:
http://www.ietf.org/internet-drafts/draft-jaseem-rap-c= ops-mip-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-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-00.txt".
       =20
NOTE:   The mail server at = ietf.org can return the document in
        MIME-encoded form by using the "mpack" = utility.  To use this
        feature, insert the command "ENCODING mime" = before the "FILE"
        command.  To decode the response(s), you will need = "munpack" or
        a MIME-compliant mail reader.  Different = MIME-compliant mail readers
        exhibit different behavior, especially when dealing = with
        "multipart" MIME messages (i.e. documents = which have been split
        up into multiple messages), so check your local = documentation on
        how to manipulate these messages.
        =        =20
        =        =20
Below is the data which will enable a = MIME compliant mail reader
implementation to automatically = retrieve the ASCII version of the
Internet-Draft.


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

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

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

ENCODING mime
FILE = /internet-drafts/draft-jaseem-rap-cops-mip-00.txt

--OtherAccess
Content-Type: = Message/External-body;
        name=3D"draft-jaseem-rap-cops-mip-00.txt";
        site=3D"ftp.ietf.org";
        access-type=3D"anon-ftp";
        directory=3D"internet-drafts"


--OtherAccess--

--NextPart--

------_=_NextPart_001_01C02E04.7921F7B0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 10:03: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 KAA20605 for ; Wed, 4 Oct 2000 10:03:23 -0400 (EDT) Received: from standards (47.234.32.16:1321) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C38A@standards.nortelnetworks.com>; Wed, 4 Oct 2000 9:47:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17726 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 09:47:00 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C389@standards.nortelnetworks.com>; Wed, 4 Oct 2000 9:46:59 -0400 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA04784; Wed, 4 Oct 2000 08:01:10 -0600 (MDT) 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 HAA11881; Wed, 4 Oct 2000 07:01:09 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA08542; Wed, 4 Oct 2000 07:01:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Wed, 4 Oct 2000 06:59:00 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Comments on draft-calhoun-mobileip-proactive-fa-02.txt X-To: "henrik@levkowetz.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <01C02DF8.20B8DFA0.henrik.levkowetz@abrandnewworld.se> > > I agree. I'm concerned, however, that the octet sub-type may be > insufficient. It may need to distinguish between not only different wireless > transmission technologies, but also between the same technology applied in > different frequency bands. -- An alternative is of course to express > link-layer address formats in such a manner that it comprises both band and > address information, when the technology itself doesn't have an address > scheme that lets you derive the frequency band from the link layer address. > Then the LLA field in 9.0 would actually be something more than a simple > link layer address. > OK, but would be, I assume, for a very specific technology, right? So, when that technology's LLA is defined, it would include the band. In the CDMA2000 part, we also encode the RLP identifier, which is not part of the MAC address itself. However, other technologies don't have such extensibility. So, do you have specific text to propose? PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 10:11: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 KAA20790 for ; Wed, 4 Oct 2000 10:11:14 -0400 (EDT) Received: from standards (47.234.32.16:1321) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C3D1@standards.nortelnetworks.com>; Wed, 4 Oct 2000 9:54:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17818 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 09:54:42 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C3D0@standards.nortelnetworks.com>; Wed, 4 Oct 2000 9:54:42 -0400 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA08973; Wed, 4 Oct 2000 08:09:03 -0600 (MDT) 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 HAA27072; Wed, 4 Oct 2000 07:08:59 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA08683; Wed, 4 Oct 2000 07:08:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Wed, 4 Oct 2000 07:06:48 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt X-To: Muhammad Jaseemuddin , alakas@NORTELNETWORKS.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" Ok, I'll be the first one to reply, and if you don't mind, I'll take off the white gloves (not that I wear them *that* often). Why? The IETF has already decided that network access (and specifically Mobile IP) authentication, authorization and accounting is done through the protocol that was selected in the AAA WG. COPS was a potential protocol, and did not succeed. So may I ask why you insist on opening up the can of worms all over again? Hasn't the past 2 years of AAA run around been enough? Am I missing something obvious? Or are some COPS people refusing to let the AAA do its work? Or is causing confusion in the marketplace the ultimate goal? PatC > We have submitted a draft defining COPS usage for Mobile IP. The > announcement is attached below. We will appreciate any comments. > > - Muhammad Jaseemuddin > > > -----Original Message----- > > From: yaniv@iphighway.com [SMTP:yaniv@iphighway.com] > > Sent: Wednesday, October 04, 2000 7:19 AM > > To: rap@iphighway.com > > Subject: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > > > To: IETF-Announce: ; > > CC: rap@iphighway.com > > From: Internet-Drafts@ietf.org > > Reply-to: Internet-Drafts@ietf.org > > Subject: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > Date: Wed, 04 Oct 2000 06:54:46 -0400 > > Sender: nsyracus@cnri.reston.va.us > > > > --NextPart > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : COPS usage for Mobile IP (MIP) > > Author(s) : M. Jaseemuddin, A. Lakas > > Filename : draft-jaseem-rap-cops-mip-00.txt > > Pages : 14 > > Date : 03-Oct-00 > > > > Mobile IP is a protocol that is used to achieve transparent routing > > of IP packets to a mobile node. A mobile node obtains a care-of- > > address in the foreign network and registers that address with the > > home agent. The home agent as well as the foreign agent can apply > > policies to the mobile node registration. This draft defines COPS > > [1] usage for Mobile IPv4 [2]. It describes how COPS is used to > > control Mobile IP registration based on policies. It defines the > > interactions between the PEP and the PDP to handle Mobile IP > > registration messages. It also provides a guideline for mobility > > agents on how to use this COPS client with regards to the > > registration messages. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-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: <20001003122806.I-D@ietf.org> > > > > ENCODING mime > > FILE /internet-drafts/draft-jaseem-rap-cops-mip-00.txt > > > > --OtherAccess > > Content-Type: Message/External-body; > > name="draft-jaseem-rap-cops-mip-00.txt"; > > site="ftp.ietf.org"; > > access-type="anon-ftp"; > > directory="internet-drafts" > > > > > > --OtherAccess-- > > > > --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 11: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 LAA21913 for ; Wed, 4 Oct 2000 11:01:24 -0400 (EDT) Received: from standards (47.234.32.16:1770) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C430@standards.nortelnetworks.com>; Wed, 4 Oct 2000 10:44:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17939 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 10:44:47 -0400 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C42B@standards.nortelnetworks.com>; Wed, 4 Oct 2000 10:34:42 -0400 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id HAA20263 for ; Wed, 4 Oct 2000 07:48:49 -0700 (MST)] Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id HAA11310 for ; Wed, 4 Oct 2000 07:48:48 -0700 (MST)] Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Oct 2000 09:48:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 4 Oct 2000 09:48:47 -0500 Reply-To: Roberts Philip-qa3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Philip-qa3445 Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt X-To: Muhammad Jaseemuddin To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I thought the AAA working group had already eliminated COPS as a AAA protocol. If so, please explain why we should be considering COPS in MIP? > ---------- > From: Muhammad Jaseemuddin > Reply To: Muhammad Jaseemuddin > Sent: Wednesday, October 4, 2000 9:10 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > We have submitted a draft defining COPS usage for Mobile IP. The > announcement is attached below. We will appreciate any comments. > > - Muhammad Jaseemuddin > > -----Original Message----- > From: yaniv@iphighway.com [SMTP:yaniv@iphighway.com] > Sent: Wednesday, October 04, 2000 7:19 AM > To: rap@iphighway.com > Subject: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > To: IETF-Announce: ; > CC: rap@iphighway.com > From: Internet-Drafts@ietf.org > Reply-to: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > Date: Wed, 04 Oct 2000 06:54:46 -0400 > Sender: nsyracus@cnri.reston.va.us > > --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : COPS usage for Mobile IP (MIP) > Author(s) : M. Jaseemuddin, A. Lakas > Filename : draft-jaseem-rap-cops-mip-00.txt > Pages : 14 > Date : 03-Oct-00 > > Mobile IP is a protocol that is used to achieve transparent routing > of IP packets to a mobile node. A mobile node obtains a care-of- > address in the foreign network and registers that address with the > home agent. The home agent as well as the foreign agent can apply > policies to the mobile node registration. This draft defines COPS > [1] usage for Mobile IPv4 [2]. It describes how COPS is used to > control Mobile IP registration based on policies. It defines the > interactions between the PEP and the PDP to handle Mobile IP > registration messages. It also provides a guideline for mobility > agents on how to use this COPS client with regards to the > registration messages. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-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: <20001003122806.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-jaseem-rap-cops-mip-00.txt > > --OtherAccess > Content-Type: Message/External-body; > name="draft-jaseem-rap-cops-mip-00.txt"; > site="ftp.ietf.org"; > access-type="anon-ftp"; > directory="internet-drafts" > > > --OtherAccess-- > > --NextPart-- > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 11:13: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 LAA22261 for ; Wed, 4 Oct 2000 11:13:50 -0400 (EDT) Received: from standards (47.234.32.16:1770) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C4A7@standards.nortelnetworks.com>; Wed, 4 Oct 2000 10:56:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18102 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 10:56:52 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C4A6@standards.nortelnetworks.com>; Wed, 4 Oct 2000 10:56:51 -0400 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 IAA12165; Wed, 4 Oct 2000 08:11:17 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e94FBFs03270; Wed, 4 Oct 2000 08:11:15 -0700 X-Virus-Scanned: Wed, 4 Oct 2000 08:11:15 -0700 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) smtpdgZJFzw; Wed, 04 Oct 2000 08:11:11 PDT 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 Message-ID: <39DB4891.4D00FE56@iprg.nokia.com> Date: Wed, 4 Oct 2000 08:11:13 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: [MOBILE-IP] Proposal for new Destination Options placement X-To: Francis Dupont X-cc: IPng Working Group To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Francis et al., I am writing this note in response to your note, appended after the main body of this note. I have been studying the issues relevant to the placement of the Home Address option and the Binding Update option, in preparation for making a new revision for Mobile IPv6. It is a tough problem. I agree with you that the existing choices for ordering AH and Destination Options are not sufficient. In my mind, the first and most serious error, that affects the placement of the Home Address option, is it has to go before AH, but there is no need at all for it to be processed by the intermediate routing points of a routing header. Therefore, I'd like to suggest that in the Mobile IPv6 specification, we enable the placement of Destination Options after the Routing Header, but before the Fragment Header. This will enable the correct placement of the Home Address destination option, and it will greatly simplify any needed firewall treatment. Regards, Charlie P. -------- Original Message -------- Subject: Re: [MOBILE-IP] Implementation Issues re MobileIP and IPSec Date: Tue, 1 Aug 2000 21:16:56 +0200 From: Francis Dupont Reply-To: Francis.Dupont@ENST-BRETAGNE.FR To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In your previous mail you wrote: > => this point was signaled by me and others... The final document > is supposed to fix it. So, the care-of-address is used as the IP source address for the authentication calculations. Correct? => we need both the home and the care-of address, one will be in the source address field, the other in the home address option. But we have to wait for the final document to know the exact order (ie. swapped (me) or not (Microsoft)). > => I disagree because you put more in "Binding Update option processing" > than it should be. In fact when you decode the BU you don't know if there > is an AH after or (the argument :-) a HA option. Now, I am confused ... Since we propose to put the BU in the 2nd Destination Options header, this problem wouldn't occur. => you can put the BU in the first/only DO header before the HA: you have replaced "MUST include" by "MUST be before" which is far stronger... (*) The only constraint in the order is there MUST be a DO header with a HA option before the AH header, you can put the BU where you'd like (before or after, in the same header than the HA or in an other one. In my code I put it in the same header than the HA in the order which gives the smallest length). By the time we get to the BU message, we have already processed the HA option (which MUST be in the 1st Destination Options header) and the AH (which MUST occur before the 2nd Destination Options header). => the second MUST is yours and obviously is incorrect because I can implement this with only one DO header... > I execute the BU only > when I see the upper layer header, the processing itself is restricted > to length/alignement checks. So, what would you say are the advantages of putting the BU in the 1st Destination Options header? => simpler, smaller, ... Or is it just convenience since only one of the Destination Options headers must be processed then? => of course it is convenience. But if you have an ESP header too our firewall implementors want to have all DO headers in clear, ie before the ESP. Then they convince me to keep the way I built the DO header before IPsec introduction and just add some code which: - puts the AH after the DO header - supports DO headers (and DO themselves) in *any* order on input Could anybody working on the "final document" respond to this question? => I'll try to catch Dave Johnson who is here (IETF, mobileip 1st session). > 2. It should clarify which address, the mobile node's Home Address or > care-of-address, must be used for the SA/SP lookup. > > => this is clearly specified in the I-D (home address must be used). Could you please point out the respective section? => section 10.2 (inbound processing must be symmetrical). Beware that IKE rules are a bit hairy (but less than IKE itself :-). Regards Francis.Dupont@enst-bretagne.fr, PS *: to put the HA option after the BU option is a favorite in the UNH mobile IPv6 test suite... From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 11:22: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 LAA22561 for ; Wed, 4 Oct 2000 11:22:01 -0400 (EDT) Received: from standards (47.234.32.16:1770) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C4D9@standards.nortelnetworks.com>; Wed, 4 Oct 2000 11:01:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18027 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 11:01:08 -0400 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C471@standards.nortelnetworks.com>; Wed, 4 Oct 2000 10:51:03 -0400 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id IAA07862 for ; Wed, 4 Oct 2000 08:05:05 -0700 (MST)] Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA00169 for ; Wed, 4 Oct 2000 08:05:04 -0700 (MST)] Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Oct 2000 10:05:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: Date: Wed, 4 Oct 2000 10:05:03 -0500 Reply-To: Roberts Philip-qa3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Philip-qa3445 Subject: Re: [MOBILE-IP] Are requirements required? X-To: Erik Anderlind To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > ---------- > From: Erik Anderlind > Reply To: Erik Anderlind > Sent: Wednesday, October 4, 2000 6:33 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Are requirements required? > > Hi Phil and Basavaray, > Hi Erik, > I have been a (passive) member of the MIP list for many years and was > also surprised by the lack of discussions preceding the charter > reorientation. > With a list as large as the MIP list, I saw no need to add "I agree too" > comments > to messages that disagreed with the narrow rescoping of the wg without > clear > discussions of the decision criteria. The comments went unanswered or > there > was little attempt to answer them. > The working group, like all IETF working group, works on rough consensus. If we only hear one objection to stop something or one proposal to start something, it's kinda up to the chairs to make a judgement. (This is kind of a recurring issue for us). So please speak up if you've got an opinion. > If the objective is to finish off the base work on the MIPv4 and v6 > protocols as they stand today, close the wg and deal with other > mobility issues in new wgs, that is OK. Is there a desire/policy to not > have wg:s active for too long? If the wg is still open to dealing with > extensions to MIP, then criteria have to be a lot more specific. > > On the MIP charter posted at IETF I didn't see anything that mentions > handoff > at all, except the last milestone which talks about both intra and > inter-domain > handoff. > Yes, that's where it is. > How some low latency handoff solutions are OK to work on while > others are not > is a mystery to me. Cutting out certain IDs just before soliciting input > for problems > they address, was not very elegant. > What exactly are you talking about? Which IDs were cut out? > Let's continue the work on making the MIP based mobility solution better > so that it will become widely deployed and not just be a solution of > last resort. > > ...Erik > Phil > Ps. I am not one among those people that have previously expressed > concerns to Sandy. > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 11:22: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 LAA22566 for ; Wed, 4 Oct 2000 11:22:02 -0400 (EDT) Received: from standards (47.234.32.16:1770) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C4DB@standards.nortelnetworks.com>; Wed, 4 Oct 2000 11:01:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18166 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 11:01:09 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C4D8@standards.nortelnetworks.com>; Wed, 4 Oct 2000 11:01:08 -0400 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 IAA12458; Wed, 4 Oct 2000 08:15:36 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e94FFY305622; Wed, 4 Oct 2000 08:15:34 -0700 X-Virus-Scanned: Wed, 4 Oct 2000 08:15:34 -0700 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) smtpd0qJBkS; Wed, 04 Oct 2000 08:15:31 PDT 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 Message-ID: <39DB4994.A9A0645A@iprg.nokia.com> Date: Wed, 4 Oct 2000 08:15:32 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] Implementation Issues re MobileIP and IPSec] X-To: Francis Dupont To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello again Francis, This is in further response to your note, appended below, but regarding the placement of the Binding Update option. I made two notes, because I thought that the IPng mailing list would not be interested in this part. The Binding Update, as you and others have mentioned, could reasonably go either in the same Destination Options header as the Home Address option, or after AH. It seems to be a matter of convenience. The Binding Update option seems to have less needs for protection against snooping than the IPv6 header. In other words, if one wanted to protect the Binding Update, then one would also want to protect the preceding IPv6 header. That implies to me that the main good reason for requiring the Binding Update to go after AH, except possibly for natural processing requirements. On the other hand, the latter is a good reason! I do see that we should make a definite specification for particular placement of the Binding Update. I would like to make the following proposal for discussion. - Allow Home Address option to be placed after the routing header but before the fragment header (as mentioned earlier) - Require Binding Update to occur after AH. The cost is additional header bytes, but the benefit is more natural header processing. I think that we ought to get this issue settled ASAP, with a specific placement, and then try to get some mileage out of using header compression to squeeze the bytes back out again. Using header compression might be more efficient if there are fewer possibilities for placement. Regards, Charlie P. -------- Original Message -------- Subject: Re: [MOBILE-IP] Implementation Issues re MobileIP and IPSec Date: Tue, 1 Aug 2000 21:16:56 +0200 From: Francis Dupont Reply-To: Francis.Dupont@ENST-BRETAGNE.FR To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In your previous mail you wrote: > => this point was signaled by me and others... The final document > is supposed to fix it. So, the care-of-address is used as the IP source address for the authentication calculations. Correct? => we need both the home and the care-of address, one will be in the source address field, the other in the home address option. But we have to wait for the final document to know the exact order (ie. swapped (me) or not (Microsoft)). > => I disagree because you put more in "Binding Update option processing" > than it should be. In fact when you decode the BU you don't know if there > is an AH after or (the argument :-) a HA option. Now, I am confused ... Since we propose to put the BU in the 2nd Destination Options header, this problem wouldn't occur. => you can put the BU in the first/only DO header before the HA: you have replaced "MUST include" by "MUST be before" which is far stronger... (*) The only constraint in the order is there MUST be a DO header with a HA option before the AH header, you can put the BU where you'd like (before or after, in the same header than the HA or in an other one. In my code I put it in the same header than the HA in the order which gives the smallest length). By the time we get to the BU message, we have already processed the HA option (which MUST be in the 1st Destination Options header) and the AH (which MUST occur before the 2nd Destination Options header). => the second MUST is yours and obviously is incorrect because I can implement this with only one DO header... > I execute the BU only > when I see the upper layer header, the processing itself is restricted > to length/alignement checks. So, what would you say are the advantages of putting the BU in the 1st Destination Options header? => simpler, smaller, ... Or is it just convenience since only one of the Destination Options headers must be processed then? => of course it is convenience. But if you have an ESP header too our firewall implementors want to have all DO headers in clear, ie before the ESP. Then they convince me to keep the way I built the DO header before IPsec introduction and just add some code which: - puts the AH after the DO header - supports DO headers (and DO themselves) in *any* order on input Could anybody working on the "final document" respond to this question? => I'll try to catch Dave Johnson who is here (IETF, mobileip 1st session). > 2. It should clarify which address, the mobile node's Home Address or > care-of-address, must be used for the SA/SP lookup. > > => this is clearly specified in the I-D (home address must be used). Could you please point out the respective section? => section 10.2 (inbound processing must be symmetrical). Beware that IKE rules are a bit hairy (but less than IKE itself :-). Regards Francis.Dupont@enst-bretagne.fr, PS *: to put the HA option after the BU option is a favorite in the UNH mobile IPv6 test suite... From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 11:35: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 LAA23743 for ; Wed, 4 Oct 2000 11:35:31 -0400 (EDT) Received: from standards (47.234.32.16:1770) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C5B8@standards.nortelnetworks.com>; Wed, 4 Oct 2000 11:19:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18354 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 11:19:17 -0400 Received: from mailhost.abrandnewworld.se (193.13.14.6:55550) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C567@standards.nortelnetworks.com>; Wed, 4 Oct 2000 11:09:17 -0400 Received: from nthele ([192.168.21.13]) by mailhost.abrandnewworld.se (8.8.8/8.8.5) with SMTP id RAA19492; Wed, 4 Oct 2000 17:22:40 +0200 (CEST) Received: by localhost with Microsoft MAPI; Wed, 4 Oct 2000 17:23:19 +0200 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <01C02E27.CA4BEE70.henrik.levkowetz@abrandnewworld.se> Date: Wed, 4 Oct 2000 17:23:18 +0200 Reply-To: "henrik@levkowetz.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Henrik Levkowetz Subject: Re: [MOBILE-IP] Comments on draft-calhoun-mobileip-proactive-fa-02.txt X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit On Wednesday, October 04, 2000 15:59, pcalhoun@eng.sun.com [SMTP:Pat.Calhoun@Eng.Sun.COM] wrote: > > > > I agree. I'm concerned, however, that the octet sub-type may be > > insufficient. It may need to distinguish between not only different wireless > > transmission technologies, but also between the same technology applied in > > different frequency bands. -- An alternative is of course to express > > link-layer address formats in such a manner that it comprises both band and > > address information, when the technology itself doesn't have an address > > scheme that lets you derive the frequency band from the link layer address. > > Then the LLA field in 9.0 would actually be something more than a simple > > link layer address. > > > OK, but would be, I assume, for a very specific technology, right? So, when > that technology's LLA is defined, it would include the band. In the CDMA2000 > part, we also encode the RLP identifier, which is not part of the MAC address > itself. However, other technologies don't have such extensibility. > > So, do you have specific text to propose? > > PatC Yes, right. I'd propose:' LLA Contains the Link Layer Address, or a composite of a Link Layer Address field and a radio band designation field for technologies where the same Link Layer Address may occur on multiple radio bands. ' Regards, Henrik From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 11:49: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 LAA24172 for ; Wed, 4 Oct 2000 11:49:43 -0400 (EDT) Received: from standards (47.234.32.16:1770) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C61D@standards.nortelnetworks.com>; Wed, 4 Oct 2000 11:33:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18593 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 11:33:06 -0400 Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C61C@standards.nortelnetworks.com>; Wed, 4 Oct 2000 11:33:06 -0400 Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA00150 for ; Wed, 4 Oct 2000 11:47:33 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA00099 for ; Wed, 4 Oct 2000 11:47:30 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Oct 2000 16:47:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <976F7C55E3B2D111A0720008C728549C04877309@en0060exch001u.uk.lucent.com> Date: Wed, 4 Oct 2000 16:47:26 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I guess this can't be done... Is this the authors' understanding too, by now? > > > -----Original Message----- > > > From: yaniv@iphighway.com [SMTP:yaniv@iphighway.com] > > > Sent: Wednesday, October 04, 2000 7:19 AM > > > To: rap@iphighway.com > > > Subject: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > > > > > To: IETF-Announce: ; > > > CC: rap@iphighway.com > > > From: Internet-Drafts@ietf.org > > > Reply-to: Internet-Drafts@ietf.org > > > Subject: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > > Date: Wed, 04 Oct 2000 06:54:46 -0400 > > > Sender: nsyracus@cnri.reston.va.us > > > > > > --NextPart > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > > > > > > Title : COPS usage for Mobile IP (MIP) > > > Author(s) : M. Jaseemuddin, A. Lakas > > > Filename : draft-jaseem-rap-cops-mip-00.txt > > > Pages : 14 > > > Date : 03-Oct-00 > > > > > > Mobile IP is a protocol that is used to achieve transparent routing > > > of IP packets to a mobile node. A mobile node obtains a care-of- > > > address in the foreign network and registers that address with the > > > home agent. The home agent as well as the foreign agent can apply > > > policies to the mobile node registration. This draft defines COPS > > > [1] usage for Mobile IPv4 [2]. It describes how COPS is used to > > > control Mobile IP registration based on policies. It defines the > > > interactions between the PEP and the PDP to handle Mobile IP > > > registration messages. It also provides a guideline for mobility > > > agents on how to use this COPS client with regards to the > > > registration messages. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-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: <20001003122806.I-D@ietf.org> > > > > > > ENCODING mime > > > FILE /internet-drafts/draft-jaseem-rap-cops-mip-00.txt > > > > > > --OtherAccess > > > Content-Type: Message/External-body; > > > name="draft-jaseem-rap-cops-mip-00.txt"; > > > site="ftp.ietf.org"; > > > access-type="anon-ftp"; > > > directory="internet-drafts" > > > > > > > > > --OtherAccess-- > > > > > > --NextPart-- > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 13:45: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 NAA27234 for ; Wed, 4 Oct 2000 13:45:53 -0400 (EDT) Received: from standards (47.234.32.16:4917) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C6EB@standards.nortelnetworks.com>; Wed, 4 Oct 2000 13:29:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18865 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 13:29:17 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C6EA@standards.nortelnetworks.com>; Wed, 4 Oct 2000 13:29:12 -0400 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 KAA26872 for ; Wed, 4 Oct 2000 10:43:40 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e94Hhbp21915 for ; Wed, 4 Oct 2000 10:43:37 -0700 X-Virus-Scanned: Wed, 4 Oct 2000 10:43:37 -0700 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) smtpd4Cr8sH; Wed, 04 Oct 2000 10:43:33 PDT 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 Message-ID: <39DB6C48.8D2BE6E2@iprg.nokia.com> Date: Wed, 4 Oct 2000 10:43:36 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "Mobility Support in IPv6" draft] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello folks, It seems that there are now multiple incompatible interpretations of the specification within the existing Internet Draft, that deals with making AH computations when the Home Address option is present. I would like to mandate (i.e., MUST) the simplest possible strategy, to wit: 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. Of course, this also means that the node receiving a packet with AH will have to follow the same algorithm, which basically just means not moving data fields at all. The only complication comes when it is necessary to look up the appropriate security association for processing either AH or ESP. That lookup, typically indexed by the Source IP address of the IPv6 header, would instead have to be indexed by the home address in the Home Address destination option. Since that destination option would occur in the packet _before_ the security header, processing is still very simple. My belief is that this is the simplest solution and makes for a really unambiguous specification, promoting both interoperability and ease of processing as well as better compatibility with existing specifications for the order of options processing. Comments will be appreciated. A message which captures a lot of the previous discussion is appended after the main body of this note. In the appended discussion, the question is raised whether a node receiving the Home Address option can easily change the way it looks up the security associations to depend on data in the Home Address option instead of the IPv6 header. I have heard that this is not a problem. I do not know the code myself, so I will rely on input from others who have the appropriate experience. Regards, Charlie P. -------- Original Message -------- Subject: Re: [MOBILE-IP] New version of "Mobility Support in IPv6" draft Date: Sat, 23 Sep 2000 19:39:11 +0200 From: Francis Dupont To: charliep@iprg.nokia.com CC: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In your previous mail you wrote: My understanding is that the current specification makes it mandatory to copy the home address into the ip6_src field of the IPv6 header. Swapping should not be performed. Here, "replace" means "copy over". I reckon that the current specification should be made unequivocal on this point. => I disagree. You need to protect both the source address and the address in the home address option (they should be the care-of and the home addresses of the mobile). If you consider a common binding update then you can see why this is important. IMHO addresses must be swapped but there are two incompatible ways to do this: - swap field contents (easy, simple but some people don't like this) - swap pointers (more difficult but keeps the packet read-only). Someone must do the choice and write the result in the draft! ---- insert big logical break delimiter at this point --------- While thinking about the effects of this requirement, I found myself wondering why. It seems like the natural processing for the mobile node, when creating the Authentication Header, would be to calculate the authentication data starting with the predictable fields of the IPv6 header and extensions with as little change as possible. => you should consider the receiving side for AH processing. When the receiving side executes the home address option then it updates the source address (the field itself (physical) and the pointer to it (logical)). The AH is after then the source address is supposed to be the home address when the AH is processed and (the important point) when the security code looks for its parameters. I would think that, typically, the IPv6 header already has the mobile node's Care-of Address inserted as the ip6_src field before the Authentication Header calculation is initiated. => it is not so clear and: - the security parameters lookup (SPD/SADB) is more important than the AH calculation itself and must be done with the home address. - the AH calculation has to deal with mobility anyway. Then, in order to make the spec work, the mobile node has to proceed as follows: - Put in its home address as ip6_src, temporarily - Do the AH thing - Restore its care-of address as ip6_src. This seems like a lot of extra work, and a very handy place to put bugs. => AH calculation is in general a very handy place to put bugs. Mobility doesn't make things worse, it just justifies we keep AH (:-). What if we make it so that the recipient uses the address in the Home Address option to select the appropriate security association? => this is an important point. The current spec makes this easy for the recipient which: - is the way AH processing is defined (cf routing header case) - puts the burden on the mobile node shoulders - works. I understand the current specification to be fashioned so that the recipient can select the security association based on the contents of the source IPv6 address in the IPv6 header. However, whether or not to actually CHANGE the fields, treating them as mutable, => swapping pointers is better for that (it was proposed by Microsoft Research people who consider the packet as read-only) seems to introduce a lot of unnecessary specification difficulties that could be avoided. Changing the way that a security association is looked up seems a lot cheaper than copying and recopying data within the challenge data. => I am not convinced by your argument. In fact I am not convinced by any argument for field or pointer swapping (:-)... Both are not obviously right but this is a minor point: the real issue is to deal with IKE (the draft proposal works, this is just a bit hard to implement and very hard to configure). If everybody hates this idea, then just forget I mentioned it! => the only thing I really hate is to have no clear statement in the current draft. It will make one half of secure mobile IPv6 implementations not interoperable with mine... Thanks Francis.Dupont@enst-bretagne.fr PS: another missing point in the current mobile IPv6 draft: the home agent is a router then can have more than one address then the draft should *accurately* specify what address the home agent MUST use as the source address of tunneled packet (the answer is obvious but a specification is better than common sense, don't forget a paranoid mobile node will check the source address of tunneled packets). (the similar issue for BA/BR is already in the mailing list archive because it simply breaks sequence number check) From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 14:07: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 OAA27610 for ; Wed, 4 Oct 2000 14:07:31 -0400 (EDT) Received: from standards (47.234.32.16:4917) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C755@standards.nortelnetworks.com>; Wed, 4 Oct 2000 13:51:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19004 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 13:51:15 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C754@standards.nortelnetworks.com>; Wed, 4 Oct 2000 13:51:15 -0400 Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id e94I5gt07379 for ; Wed, 4 Oct 2000 20:05:42 +0200 (MEST) Received: FROM esealnt172.ericsson.se BY esealnt461 ; Wed Oct 04 19:59:28 2000 +0200 Received: by esealnt172 with Internet Mail Service (5.5.2651.58) id <4GAKM6CA>; Wed, 4 Oct 2000 20:05:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <5F05C89FB2F8D211B6430008C791912703EA81A6@esealnt190> Date: Wed, 4 Oct 2000 20:05:41 +0200 Reply-To: "Karim El-Malki (ERA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Karim El-Malki (ERA)" Subject: [MOBILE-IP] Differences between the two MIPv4 handoff approaches To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello, I am sending out a list of differences between the two handoff drafts (draft-calhoun-mobileip-proactive-fa-02 and draft-elmalki-mobileip-fast-handoffs-03) which Hesham and I already sent out to the MIPv4 handoffs team. I hope it will be useful for the WG's handoff discussions. Regards, Karim Proactive Handoffs draft = draft-calhoun-mobileip-proactive-fa-02 Fast Handoffs draft = draft-elmalki-mobileip-fast-handoffs-03 1) The Fast Handoffs draft allows both the network and the MN to control L3 handoffs just as normal Mobile IP (RFC2002). The MN performs Mobile IP Registrations and is therefore in control as to when and with which agent it registers. The network is also in control since it may decide whether to send the MN an agent advertisement to trigger the MN's movement (without which the MN will not perform movement detection and MIP Registration). The network may also advertise but reject the MN's Registration and thus again exercise control. In Proactive handoffs the MN has no control over the handoff and may only react to the network-controlled handoff after it has obtained L2 connectivity to the new FA and starts receiving data from it. Thus the handoff is forced on the MN and the MN may only react if and when the new FA decides to advertise. 2) The Fast Handoffs draft allows the MN to register with the new FA (or GFA) before it moves and before it obtains L2 connectivity to that new FA, thus anticipating the MN's movement. By interacting with L2 it is possible for the FA to synchronize such a registration with the cellular network's mobility such that the new Registration is completed before the MN is instructed to perform a handoff at L2. Local HA functionality (GFA) is used to limit the RTT for the MN's registration. In this way we potentially eliminate the service disruption caused by L3 handoffs and limit the MN's service disruption period to that imposed by the specific L2. 3) The same amount of Registrations/Advertisement are sent/received by an active MN using Proactive or Fast Handoffs for the support of real-time services such as VoIP. The main difference is that in Fast Handoffs the Registration is performed by the MN before it performs a handoff to the new FA, while in Proactive handoffs this is done after the MN has performed a handoff to the new FA and once it is receiving traffic through the new FA. 4) It is not clear in the proactive approach how an intersystem handoff is handled. For example a handoff occuring between two different wireless technologies. If the proactive approach is to be used for handoffs, and if the MN has a choice of two different systems, it is not possible for the MN to choose which FA it wants to be connected to (until after the MN has been handed off to the new FA). Hence a handoff may result in connecting the MN to a less preferred FA. This is especially true if the FAs choose not to send agent advertisements for very long periods as suggested by the draft. This situation will not arise in Fast Handoffs. 5) The proactive draft states that a FA MAY choose to send an Agent Advertisement to the MN after the handoff has taken place. The length of time after which the advertisement is sent is unclear. If simultaneous bindings are used (which is suggested by the draft), this will result in long lifetimes for the simultaneous bindings and consequently an inefficient use of bandwidth since multiple copies of the same packet are transmitted to FAs. In Fast Handoffs simultaneous bindings will have short lifetimes in order to minimize bandwidth consumption. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 14:14: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 OAA27847 for ; Wed, 4 Oct 2000 14:14:39 -0400 (EDT) Received: from standards (47.234.32.16:4917) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C78C@standards.nortelnetworks.com>; Wed, 4 Oct 2000 13:56:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19002 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 13:56:23 -0400 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C752@standards.nortelnetworks.com>; Wed, 4 Oct 2000 13:46:18 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id KAA16605 for ; Wed, 4 Oct 2000 10:56:30 -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 KAA10252 for ; Wed, 4 Oct 2000 10:56:29 -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.2650.21) id TT7QBFTH; Wed, 4 Oct 2000 12:56:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: Date: Wed, 4 Oct 2000 13:03:58 -0500 Reply-To: Ajoy Singh Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ajoy Singh Subject: Re: [MOBILE-IP] Comments on draft-calhoun-mobileip-proactive-fa-02.txt X-To: henrik@levkowetz.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <01C02E27.CA4BEE70.henrik.levkowetz@abrandnewworld.se> Content-Transfer-Encoding: 7bit Hello Pat/All, How about the idea of documenting the details of LLA encoding in some informational draft ? If you like the idea, we can come up with such a document and keep on adding new stuff based on others' comments. This will avoid frequent changes in proactive draft. regards, ajoy I was just thinking of having an informational draft that can talk about the details of LLA encoding for different technologies. If everybody like the idea, we can start working on this. This way we do not have to provide these details in proactive draft. regards, ajoy -----Original Message----- From: IP Routing for Wireless/Mobile Hosts (mobile-ip) [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Henrik Levkowetz Sent: Wednesday, October 04, 2000 10:23 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Comments on draft-calhoun-mobileip-proactive-fa-02.txt On Wednesday, October 04, 2000 15:59, pcalhoun@eng.sun.com [SMTP:Pat.Calhoun@Eng.Sun.COM] wrote: > > > > I agree. I'm concerned, however, that the octet sub-type may be > > insufficient. It may need to distinguish between not only different wireless > > transmission technologies, but also between the same technology applied in > > different frequency bands. -- An alternative is of course to express > > link-layer address formats in such a manner that it comprises both band and > > address information, when the technology itself doesn't have an address > > scheme that lets you derive the frequency band from the link layer address. > > Then the LLA field in 9.0 would actually be something more than a simple > > link layer address. > > > OK, but would be, I assume, for a very specific technology, right? So, when > that technology's LLA is defined, it would include the band. In the CDMA2000 > part, we also encode the RLP identifier, which is not part of the MAC address > itself. However, other technologies don't have such extensibility. > > So, do you have specific text to propose? > > PatC Yes, right. I'd propose:' LLA Contains the Link Layer Address, or a composite of a Link Layer Address field and a radio band designation field for technologies where the same Link Layer Address may occur on multiple radio bands. ' Regards, Henrik From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 14:22: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 OAA28065 for ; Wed, 4 Oct 2000 14:22:06 -0400 (EDT) Received: from standards (47.234.32.16:4917) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C7CC@standards.nortelnetworks.com>; Wed, 4 Oct 2000 14:00:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19003 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 14:00:28 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C753@standards.nortelnetworks.com>; Wed, 4 Oct 2000 13:50:27 -0400 Received: from purol.East.Sun.COM ([129.148.9.11]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA08972; Wed, 4 Oct 2000 11:04:23 -0700 (PDT) Received: from onion.east.sun.com (onion [129.148.174.110]) by purol.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id OAA10509; Wed, 4 Oct 2000 14:03:57 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Wed, 4 Oct 2000 14:03:50 -0400 Reply-To: Steven Glass - Solaris Software Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Steven Glass - Solaris Software Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt X-To: Roberts Philip-qa3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" > I thought the AAA working group had already eliminated COPS as a AAA > protocol. If so, please explain why we should be considering COPS in MIP? I know this is going to get dinged by many of the people I work with (on this list, and in the office), but is there some reason the authors can't have an individual submission for an informational RFC? RFC2356 comes to mind (use of SKIP FW traversal in Mobile IP), published by the mobile ip working group in June 1998, after the decision of the IPSec WG (and Jeff Schiller) for ISAKMP/Oakley as the IPSec protocol of choice. If the authors want to work on this, it doesn't have to be an official working group document (hence the name d-jaseem-..., not d-i-mip-...) to get some review from mobile ip WG members willing to read it (if any, and presuming it works). If the authors want to move it to anything more than informational, however, it seems likely to be blocked by the IESG... Cheers, Steve > > ---------- > > From: Muhammad Jaseemuddin > > Reply To: Muhammad Jaseemuddin > > Sent: Wednesday, October 4, 2000 9:10 PM > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > > > We have submitted a draft defining COPS usage for Mobile IP. The > > announcement is attached below. We will appreciate any comments. > > > > - Muhammad Jaseemuddin > > > > -----Original Message----- > > From: yaniv@iphighway.com [SMTP:yaniv@iphighway.com] > > Sent: Wednesday, October 04, 2000 7:19 AM > > To: rap@iphighway.com > > Subject: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > > > To: IETF-Announce: ; > > CC: rap@iphighway.com > > From: Internet-Drafts@ietf.org > > Reply-to: Internet-Drafts@ietf.org > > Subject: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > Date: Wed, 04 Oct 2000 06:54:46 -0400 > > Sender: nsyracus@cnri.reston.va.us > > > > --NextPart > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : COPS usage for Mobile IP (MIP) > > Author(s) : M. Jaseemuddin, A. Lakas > > Filename : draft-jaseem-rap-cops-mip-00.txt > > Pages : 14 > > Date : 03-Oct-00 > > > > Mobile IP is a protocol that is used to achieve transparent routing > > of IP packets to a mobile node. A mobile node obtains a care-of- > > address in the foreign network and registers that address with the > > home agent. The home agent as well as the foreign agent can apply > > policies to the mobile node registration. This draft defines COPS > > [1] usage for Mobile IPv4 [2]. It describes how COPS is used to > > control Mobile IP registration based on policies. It defines the > > interactions between the PEP and the PDP to handle Mobile IP > > registration messages. It also provides a guideline for mobility > > agents on how to use this COPS client with regards to the > > registration messages. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-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: <20001003122806.I-D@ietf.org> > > > > ENCODING mime > > FILE /internet-drafts/draft-jaseem-rap-cops-mip-00.txt > > > > --OtherAccess > > Content-Type: Message/External-body; > > name="draft-jaseem-rap-cops-mip-00.txt"; > > site="ftp.ietf.org"; > > access-type="anon-ftp"; > > directory="internet-drafts" > > > > > > --OtherAccess-- > > > > --NextPart-- > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 14:22: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 OAA28068 for ; Wed, 4 Oct 2000 14:22:08 -0400 (EDT) Received: from standards (47.234.32.16:4917) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C7FC@standards.nortelnetworks.com>; Wed, 4 Oct 2000 14:03:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19034 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 14:03:39 -0400 Received: from web3901.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C76D@standards.nortelnetworks.com>; Wed, 4 Oct 2000 13:53:38 -0400 Received: from [207.96.193.44] by web3901.mail.yahoo.com; Wed, 04 Oct 2000 11:08:06 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20001004180806.23585.qmail@web3901.mail.yahoo.com> Date: Wed, 4 Oct 2000 11:08:06 -0700 Reply-To: Behcet Sarikaya Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Behcet Sarikaya Subject: Re: [MOBILE-IP] Fun a la mipv4 et mipv6 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Will the SCRAP WG accept only the contributions that suck? For a definition of 'suck' please refer to Alassio's email and for a definition of SCRAP WG please refer to PatC's email. --behcet ===== Behcet Sarikaya Univ. of Aizu Aizu, Japan __________________________________________________ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 14:41: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 OAA28473 for ; Wed, 4 Oct 2000 14:40:59 -0400 (EDT) Received: from standards (47.234.32.16:4917) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C897@standards.nortelnetworks.com>; Wed, 4 Oct 2000 14:24:31 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19418 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 14:24:31 -0400 Received: from alemail1.firewall.lucent.com (alemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C896@standards.nortelnetworks.com>; Wed, 4 Oct 2000 14:24:31 -0400 Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA03337 for ; Wed, 4 Oct 2000 14:38:59 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA03331 for ; Wed, 4 Oct 2000 14:38:59 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Oct 2000 19:38:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C0487730E@en0060exch001u.uk.lucent.com> Date: Wed, 4 Oct 2000 19:38:57 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > I know this is going to get dinged by many of the people I work with > (on > this list, and in the office), but is there some reason the authors can't > have > an individual submission for an informational RFC? RFC2356 comes to mind > (use > of SKIP FW traversal in Mobile IP), published by the mobile ip working > group > in June 1998, after the decision of the IPSec WG (and Jeff Schiller) for > ISAKMP/Oakley as the IPSec protocol of choice. If the authors want to > work on > this, it doesn't have to be an official working group document (hence the > name > d-jaseem-..., not d-i-mip-...) to get some review from mobile ip WG > members > willing to read it (if any, and presuming it works). If the authors want > to > move it to anything more than informational, however, it seems likely to > be > blocked by the IESG... > > Your line of reasoning is somewhat valid in general terms to me. However, this intention should have been clear either from the posting from the authors or from the abstract. Neither guides us in that direction. Nor mention of the currently selected approach is anywhere in the document. Of course, if they authors to go for an individual info RFC, they can try, but I would claim that since COPS is standards track too, things may not be as similar to SKIP firewall traversal as it may look like :). Let's wait and see what the authors want to tell us (if they are on this ML) alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 14:48: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 OAA28812 for ; Wed, 4 Oct 2000 14:48:48 -0400 (EDT) Received: from standards (47.234.32.16:4917) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C8C6@standards.nortelnetworks.com>; Wed, 4 Oct 2000 14:29:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19415 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 14:29:31 -0400 Received: from qhars002.nortel.com (47.101.112.102:64744) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C891@standards.nortelnetworks.com>; Wed, 4 Oct 2000 14:19:30 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Wed, 4 Oct 2000 19:31:43 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Wed, 4 Oct 2000 14:29:55 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 4 Oct 2000 14:29:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02E31.0551B550" Message-ID: <488891341182D4118A870000F80822E701226491@zcard00p.ca.nortel.com> Date: Wed, 4 Oct 2000 14:29:24 -0400 Reply-To: Abderrahmane Lakas Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Abderrahmane Lakas Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt 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_01C02E31.0551B550 Content-Type: text/plain; charset="iso-8859-1" The comments to this draft are understood and well taken. Let me just clarify that our intent (authors) is neither to use COPS as a protocol for AAA, nor to open up any AAA-COPS discussion on whatever aspects of management. COPS is used here for non-AAA related aspects of Mobile IP. In our draft, we propose a way to notify the PDP with the presence of MN for which policy-related configurations may be applied. COPS looks at the relevant extensions in the registration messages in order to make policy-related decisions. The AAA extensions are handled by AAA authority. We understand that we may not have highlighted it enough in the draft, but we are not in any way proposing AAA solution for Mobile IP. Our assumptions here is that AAA handles AAA things, and COPS handles policy-related things. It's not clear yet for us how both coordinate, but we assume that the PDP needs to know an MN has attached to the mobility agent, and policies may need to be applied to it. For example, based on the received extensions, the PDP may decide to install the MN's QoS profile. Other extensions that are or will be defined in the future may require some policy-management through COPS. Finally, this proposal has merit only if COPS is used for policy management. - Abderrahmane -----Original Message----- From: pcalhoun@eng.sun.com [mailto:Pat.Calhoun@ENG.SUN.COM] Sent: Wednesday, October 04, 2000 10:07 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt Ok, I'll be the first one to reply, and if you don't mind, I'll take off the white gloves (not that I wear them *that* often). Why? The IETF has already decided that network access (and specifically Mobile IP) authentication, authorization and accounting is done through the protocol that was selected in the AAA WG. COPS was a potential protocol, and did not succeed. So may I ask why you insist on opening up the can of worms all over again? Hasn't the past 2 years of AAA run around been enough? Am I missing something obvious? Or are some COPS people refusing to let the AAA do its work? Or is causing confusion in the marketplace the ultimate goal? PatC > We have submitted a draft defining COPS usage for Mobile IP. The > announcement is attached below. We will appreciate any comments. > > - Muhammad Jaseemuddin > > > -----Original Message----- > > From: yaniv@iphighway.com [SMTP:yaniv@iphighway.com] > > Sent: Wednesday, October 04, 2000 7:19 AM > > To: rap@iphighway.com > > Subject: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > > > To: IETF-Announce: ; > > CC: rap@iphighway.com > > From: Internet-Drafts@ietf.org > > Reply-to: Internet-Drafts@ietf.org > > Subject: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > Date: Wed, 04 Oct 2000 06:54:46 -0400 > > Sender: nsyracus@cnri.reston.va.us > > > > --NextPart > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : COPS usage for Mobile IP (MIP) > > Author(s) : M. Jaseemuddin, A. Lakas > > Filename : draft-jaseem-rap-cops-mip-00.txt > > Pages : 14 > > Date : 03-Oct-00 > > > > Mobile IP is a protocol that is used to achieve transparent routing > > of IP packets to a mobile node. A mobile node obtains a care-of- > > address in the foreign network and registers that address with the > > home agent. The home agent as well as the foreign agent can apply > > policies to the mobile node registration. This draft defines COPS > > [1] usage for Mobile IPv4 [2]. It describes how COPS is used to > > control Mobile IP registration based on policies. It defines the > > interactions between the PEP and the PDP to handle Mobile IP > > registration messages. It also provides a guideline for mobility > > agents on how to use this COPS client with regards to the > > registration messages. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-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: <20001003122806.I-D@ietf.org> > > > > ENCODING mime > > FILE /internet-drafts/draft-jaseem-rap-cops-mip-00.txt > > > > --OtherAccess > > Content-Type: Message/External-body; > > name="draft-jaseem-rap-cops-mip-00.txt"; > > site="ftp.ietf.org"; > > access-type="anon-ftp"; > > directory="internet-drafts" > > > > > > --OtherAccess-- > > > > --NextPart-- ------_=_NextPart_001_01C02E31.0551B550 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] FW: I-D = ACTION:draft-jaseem-rap-cops-mip-00.txt

The comments to this draft are understood and well = taken. Let me just clarify that our intent (authors) is neither to use = COPS as a protocol for AAA, nor to open up any AAA-COPS discussion on = whatever aspects of management.

COPS is used here for non-AAA related aspects of = Mobile IP. In our draft, we propose a way to notify the PDP with the = presence of MN for which policy-related configurations may be applied. = COPS looks at the relevant extensions in the registration messages in = order to make policy-related decisions. The AAA extensions are handled = by AAA authority.

We understand that we may not have highlighted it = enough in the draft, but we are not in any way proposing AAA solution = for Mobile IP.

Our assumptions here is that AAA handles AAA things, = and COPS handles policy-related things. It's not clear yet for us how = both coordinate, but we assume that the PDP needs to know an MN has = attached to the mobility agent, and policies may need to be applied to = it. For example, based on the received extensions, the PDP may decide = to install the MN's QoS profile. Other extensions that are or will be = defined in the future may require some policy-management through = COPS.

Finally, this proposal has merit only if COPS is used = for policy management.

- Abderrahmane

-----Original Message-----
From: pcalhoun@eng.sun.com [mailto:Pat.Calhoun@ENG.SUN.COM]
Sent: Wednesday, October 04, 2000 10:07 AM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] FW: I-D = ACTION:draft-jaseem-rap-cops-mip-00.txt


Ok, I'll be the first one to reply, and if you don't = mind, I'll take off the
white gloves (not that I wear them *that* = often).

Why?

The IETF has already decided that network access (and = specifically Mobile IP)
authentication, authorization and accounting is done = through the protocol that
was selected in the AAA WG. COPS was a potential = protocol, and did not succeed.
 So may I ask why you insist on opening up the = can of worms all over again?
Hasn't the past 2 years of AAA run around been = enough?

Am I missing something obvious? Or are some COPS = people refusing to let the
AAA do its work? Or is causing confusion in the = marketplace the ultimate goal?

PatC

> We have submitted a draft defining COPS usage = for Mobile IP. The
> announcement is attached below. We will = appreciate any comments.
>
> - Muhammad Jaseemuddin
>
> > -----Original Message-----
> > From: yaniv@iphighway.com = [SMTP:yaniv@iphighway.com]
> > Sent: Wednesday, October 04, 2000 7:19 = AM
> > To:   rap@iphighway.com
> > Subject:      I-D = ACTION:draft-jaseem-rap-cops-mip-00.txt
> >
> > To: IETF-Announce: ;
> > CC: rap@iphighway.com
> > From: Internet-Drafts@ietf.org
> > Reply-to: Internet-Drafts@ietf.org
> > Subject: I-D = ACTION:draft-jaseem-rap-cops-mip-00.txt
> > Date: Wed, 04 Oct 2000 06:54:46 = -0400
> > Sender: nsyracus@cnri.reston.va.us
> >
> > --NextPart
> >
> > A New Internet-Draft is available from the = on-line Internet-Drafts
> > directories.
> >
> >
> >       = Title           : = COPS usage for Mobile IP (MIP)
> >       = Author(s)       : M. Jaseemuddin, A. = Lakas
> >       = Filename        : = draft-jaseem-rap-cops-mip-00.txt
> >       = Pages           : = 14
> >       = Date            = : 03-Oct-00
> >
> > Mobile IP is a protocol that is used to = achieve transparent routing
> > of IP packets to a mobile node. A mobile = node obtains a care-of-
> > address in the foreign network and = registers that address with the
> > home agent. The home agent as well as the = foreign agent can apply
> > policies to the mobile node registration. = This draft defines COPS
> > [1] usage for Mobile IPv4 [2]. It = describes how COPS is used to
> > control Mobile IP registration based on = policies. It defines the
> > interactions between the PEP and the PDP = to handle Mobile IP
> > registration messages. It also provides a = guideline for mobility
> > agents on how to use this COPS client with = regards to the
> > registration messages.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-jaseem-rap-c= ops-mip-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-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-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=3D"OtherAccess"
> >
> > --OtherAccess
> > Content-Type: = Message/External-body;
> >       = access-type=3D"mail-server";
> >       = server=3D"mailserv@ietf.org"
> >
> > Content-Type: text/plain
> > Content-ID:   = <20001003122806.I-D@ietf.org>
> >
> > ENCODING mime
> > FILE = /internet-drafts/draft-jaseem-rap-cops-mip-00.txt
> >
> > --OtherAccess
> > Content-Type: = Message/External-body;
> >       = name=3D"draft-jaseem-rap-cops-mip-00.txt";
> >       = site=3D"ftp.ietf.org";
> >       = access-type=3D"anon-ftp";
> >       = directory=3D"internet-drafts"
> >
> >
> > --OtherAccess--
> >
> > --NextPart--

------_=_NextPart_001_01C02E31.0551B550-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 14:55: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 OAA28989 for ; Wed, 4 Oct 2000 14:55:37 -0400 (EDT) Received: from standards (47.234.32.16:4917) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C935@standards.nortelnetworks.com>; Wed, 4 Oct 2000 14:39:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19623 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 14:39:11 -0400 Received: from topaz.3com.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C934@standards.nortelnetworks.com>; Wed, 4 Oct 2000 14:39:11 -0400 Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e94Ir6220720; Wed, 4 Oct 2000 11:53:06 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e94IrWs15490; Wed, 4 Oct 2000 11:53:32 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 8825696E.0067F64F ; Wed, 4 Oct 2000 11:55:32 -0700 X-Lotus-FromDomain: 3COM Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <8825696E.0067F14A.00@hqoutbound.ops.3com.com> Date: Wed, 4 Oct 2000 13:59:17 -0500 Reply-To: Phil_Neumiller@3COM.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Phil Neumiller Subject: Re: [MOBILE-IP] Fun a la mipv4 et mipv6 X-To: Behcet Sarikaya To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM No they have to stink, not suck! No really, giant sucking sounds exist in all working groups, and the rough consensus is that they all MUST go. The SCRAP WG SHOULD be called SeaMoby. Whales tend to make a sucking sound and a blowing sound through their blow holes. -Phil "Call me Ishmael" Neumiller >Will the SCRAP WG accept only the contributions that suck? >For a definition of 'suck' please refer to Alassio's >email and for a definition of SCRAP WG please refer to >PatC's email. > >--behcet > > >===== >Behcet Sarikaya >Univ. of Aizu >Aizu, Japan > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 15:28: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 PAA29645 for ; Wed, 4 Oct 2000 15:28:51 -0400 (EDT) Received: from standards (47.234.32.16:4917) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C9BA@standards.nortelnetworks.com>; Wed, 4 Oct 2000 15:12:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19801 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 15:12:22 -0400 Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C9B9@standards.nortelnetworks.com>; Wed, 4 Oct 2000 15:12:22 -0400 Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA19526 for ; Wed, 4 Oct 2000 15:26:50 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA19517 for ; Wed, 4 Oct 2000 15:26:50 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Oct 2000 20:26:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <976F7C55E3B2D111A0720008C728549C04877311@en0060exch001u.uk.lucent.com> Date: Wed, 4 Oct 2000 20:26:48 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt X-To: Abderrahmane Lakas To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM My question is: if some form of policy management will be performed using COPS, what makes the PEP/PDP interaction inherently different when mobile IP is used? I ask this question without having carefully read the draft, but, if you have time, this could make your proposal's scope clearer. thanks alessio > ---------- > From: Abderrahmane Lakas[SMTP:alakas@NORTELNETWORKS.COM] > Reply To: Abderrahmane Lakas > Sent: 04 October 2000 19:29 > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] FW: I-D > ACTION:draft-jaseem-rap-cops-mip-00.txt > > The comments to this draft are understood and well taken. Let me just > clarify that our intent (authors) is neither to use COPS as a protocol for > AAA, nor to open up any AAA-COPS discussion on whatever aspects of > management. > > COPS is used here for non-AAA related aspects of Mobile IP. In our draft, > we propose a way to notify the PDP with the presence of MN for which > policy-related configurations may be applied. COPS looks at the relevant > extensions in the registration messages in order to make policy-related > decisions. The AAA extensions are handled by AAA authority. > > We understand that we may not have highlighted it enough in the draft, but > we are not in any way proposing AAA solution for Mobile IP. > > Our assumptions here is that AAA handles AAA things, and COPS handles > policy-related things. It's not clear yet for us how both coordinate, but > we assume that the PDP needs to know an MN has attached to the mobility > agent, and policies may need to be applied to it. For example, based on > the received extensions, the PDP may decide to install the MN's QoS > profile. Other extensions that are or will be defined in the future may > require some policy-management through COPS. > > Finally, this proposal has merit only if COPS is used for policy > management. > > - Abderrahmane > > -----Original Message----- > From: pcalhoun@eng.sun.com [ mailto:Pat.Calhoun@ENG.SUN.COM] > Sent: Wednesday, October 04, 2000 10:07 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > > Ok, I'll be the first one to reply, and if you don't mind, I'll take off > the > white gloves (not that I wear them *that* often). > > Why? > > The IETF has already decided that network access (and specifically Mobile > IP) > authentication, authorization and accounting is done through the protocol > that > was selected in the AAA WG. COPS was a potential protocol, and did not > succeed. > So may I ask why you insist on opening up the can of worms all over > again? > Hasn't the past 2 years of AAA run around been enough? > > Am I missing something obvious? Or are some COPS people refusing to let > the > AAA do its work? Or is causing confusion in the marketplace the ultimate > goal? > > PatC > > > We have submitted a draft defining COPS usage for Mobile IP. The > > announcement is attached below. We will appreciate any comments. > > > > - Muhammad Jaseemuddin > > > > > -----Original Message----- > > > From: yaniv@iphighway.com [SMTP:yaniv@iphighway.com] > > > Sent: Wednesday, October 04, 2000 7:19 AM > > > To: rap@iphighway.com > > > Subject: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > > > > > To: IETF-Announce: ; > > > CC: rap@iphighway.com > > > From: Internet-Drafts@ietf.org > > > Reply-to: Internet-Drafts@ietf.org > > > Subject: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > > Date: Wed, 04 Oct 2000 06:54:46 -0400 > > > Sender: nsyracus@cnri.reston.va.us > > > > > > --NextPart > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > > > > > > Title : COPS usage for Mobile IP (MIP) > > > Author(s) : M. Jaseemuddin, A. Lakas > > > Filename : draft-jaseem-rap-cops-mip-00.txt > > > Pages : 14 > > > Date : 03-Oct-00 > > > > > > Mobile IP is a protocol that is used to achieve transparent routing > > > of IP packets to a mobile node. A mobile node obtains a care-of- > > > address in the foreign network and registers that address with the > > > home agent. The home agent as well as the foreign agent can apply > > > policies to the mobile node registration. This draft defines COPS > > > [1] usage for Mobile IPv4 [2]. It describes how COPS is used to > > > control Mobile IP registration based on policies. It defines the > > > interactions between the PEP and the PDP to handle Mobile IP > > > registration messages. It also provides a guideline for mobility > > > agents on how to use this COPS client with regards to the > > > registration messages. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-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: <20001003122806.I-D@ietf.org> > > > > > > ENCODING mime > > > FILE /internet-drafts/draft-jaseem-rap-cops-mip-00.txt > > > > > > --OtherAccess > > > Content-Type: Message/External-body; > > > name="draft-jaseem-rap-cops-mip-00.txt"; > > > site="ftp.ietf.org"; > > > access-type="anon-ftp"; > > > directory="internet-drafts" > > > > > > > > > --OtherAccess-- > > > > > > --NextPart-- > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 15:42: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 PAA29951 for ; Wed, 4 Oct 2000 15:42:30 -0400 (EDT) Received: from standards (47.234.32.16:4917) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9CA19@standards.nortelnetworks.com>; Wed, 4 Oct 2000 15:25:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19925 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 15:25:54 -0400 Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9CA18@standards.nortelnetworks.com>; Wed, 4 Oct 2000 15:25:54 -0400 Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA01324 for ; Wed, 4 Oct 2000 15:40:22 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA01317 for ; Wed, 4 Oct 2000 15:40:21 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Oct 2000 20:40:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <976F7C55E3B2D111A0720008C728549C04877312@en0060exch001u.uk.lucent.com> Date: Wed, 4 Oct 2000 20:40:13 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In particular, clarifying why you need this would be helpful... 4. Handling MIP authentication extensions If the PDP is delegated to perform authentication, the PEP MUST send the FLO for the registration message followed by an extension object, all encapsulated in a client SI object. The extension object MUST contain all extensions including the authentication extension that the PDP is required to process, in the order they appear in the message. See section 3.5 in [4] for the ordering and processing requirements of authentication extensions, and [5] for AAA requirements. If an authentication fails, the PDP is required to include the appropriate authentication failure code in the decision message. > ---------- > From: Casati, Alessio (Alessio)[SMTP:acasati@LUCENT.COM] > Reply To: Casati, Alessio (Alessio) > Sent: 04 October 2000 20:26 > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] FW: I-D > ACTION:draft-jaseem-rap-cops-mip-00.txt > > My question is: if some form of policy management will be performed using > COPS, what makes the PEP/PDP interaction inherently different > when mobile IP is used? > > I ask this question without having carefully read the draft, > but, if you have time, this could make your proposal's > scope clearer. > > > thanks > > > alessio > > > ---------- > > From: Abderrahmane Lakas[SMTP:alakas@NORTELNETWORKS.COM] > > Reply To: Abderrahmane Lakas > > Sent: 04 October 2000 19:29 > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: [MOBILE-IP] FW: I-D > > ACTION:draft-jaseem-rap-cops-mip-00.txt > > > > The comments to this draft are understood and well taken. Let me just > > clarify that our intent (authors) is neither to use COPS as a protocol > for > > AAA, nor to open up any AAA-COPS discussion on whatever aspects of > > management. > > > > COPS is used here for non-AAA related aspects of Mobile IP. In our > draft, > > we propose a way to notify the PDP with the presence of MN for which > > policy-related configurations may be applied. COPS looks at the relevant > > extensions in the registration messages in order to make policy-related > > decisions. The AAA extensions are handled by AAA authority. > > > > We understand that we may not have highlighted it enough in the draft, > but > > we are not in any way proposing AAA solution for Mobile IP. > > > > Our assumptions here is that AAA handles AAA things, and COPS handles > > policy-related things. It's not clear yet for us how both coordinate, > but > > we assume that the PDP needs to know an MN has attached to the mobility > > agent, and policies may need to be applied to it. For example, based on > > the received extensions, the PDP may decide to install the MN's QoS > > profile. Other extensions that are or will be defined in the future may > > require some policy-management through COPS. > > > > Finally, this proposal has merit only if COPS is used for policy > > management. > > > > - Abderrahmane > > > > -----Original Message----- > > From: pcalhoun@eng.sun.com [ mailto:Pat.Calhoun@ENG.SUN.COM] > > Sent: Wednesday, October 04, 2000 10:07 AM > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > > > > > Ok, I'll be the first one to reply, and if you don't mind, I'll take off > > the > > white gloves (not that I wear them *that* often). > > > > Why? > > > > The IETF has already decided that network access (and specifically > Mobile > > IP) > > authentication, authorization and accounting is done through the > protocol > > that > > was selected in the AAA WG. COPS was a potential protocol, and did not > > succeed. > > So may I ask why you insist on opening up the can of worms all over > > again? > > Hasn't the past 2 years of AAA run around been enough? > > > > Am I missing something obvious? Or are some COPS people refusing to let > > the > > AAA do its work? Or is causing confusion in the marketplace the ultimate > > goal? > > > > PatC > > > > > We have submitted a draft defining COPS usage for Mobile IP. The > > > announcement is attached below. We will appreciate any comments. > > > > > > - Muhammad Jaseemuddin > > > > > > > -----Original Message----- > > > > From: yaniv@iphighway.com [SMTP:yaniv@iphighway.com] > > > > Sent: Wednesday, October 04, 2000 7:19 AM > > > > To: rap@iphighway.com > > > > Subject: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > > > > > > > To: IETF-Announce: ; > > > > CC: rap@iphighway.com > > > > From: Internet-Drafts@ietf.org > > > > Reply-to: Internet-Drafts@ietf.org > > > > Subject: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > > > Date: Wed, 04 Oct 2000 06:54:46 -0400 > > > > Sender: nsyracus@cnri.reston.va.us > > > > > > > > --NextPart > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > > directories. > > > > > > > > > > > > Title : COPS usage for Mobile IP (MIP) > > > > Author(s) : M. Jaseemuddin, A. Lakas > > > > Filename : draft-jaseem-rap-cops-mip-00.txt > > > > Pages : 14 > > > > Date : 03-Oct-00 > > > > > > > > Mobile IP is a protocol that is used to achieve transparent routing > > > > of IP packets to a mobile node. A mobile node obtains a care-of- > > > > address in the foreign network and registers that address with the > > > > home agent. The home agent as well as the foreign agent can apply > > > > policies to the mobile node registration. This draft defines COPS > > > > [1] usage for Mobile IPv4 [2]. It describes how COPS is used to > > > > control Mobile IP registration based on policies. It defines the > > > > interactions between the PEP and the PDP to handle Mobile IP > > > > registration messages. It also provides a guideline for mobility > > > > agents on how to use this COPS client with regards to the > > > > registration messages. > > > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-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: <20001003122806.I-D@ietf.org> > > > > > > > > ENCODING mime > > > > FILE /internet-drafts/draft-jaseem-rap-cops-mip-00.txt > > > > > > > > --OtherAccess > > > > Content-Type: Message/External-body; > > > > name="draft-jaseem-rap-cops-mip-00.txt"; > > > > site="ftp.ietf.org"; > > > > access-type="anon-ftp"; > > > > directory="internet-drafts" > > > > > > > > > > > > --OtherAccess-- > > > > > > > > --NextPart-- > > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 15:42: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 PAA29954 for ; Wed, 4 Oct 2000 15:42:31 -0400 (EDT) Received: from standards (47.234.32.16:4917) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9CA23@standards.nortelnetworks.com>; Wed, 4 Oct 2000 15:26:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19881 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 15:26:46 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C9F6@standards.nortelnetworks.com>; Wed, 4 Oct 2000 15:16:46 -0400 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA20260; Wed, 4 Oct 2000 13:31:13 -0600 (MDT) 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 MAA06866; Wed, 4 Oct 2000 12:31:12 -0700 (PDT) Received: (from mohanp@localhost) by locked.eng.sun.com (8.10.1+Sun/8.10.1) id e94JUAA00260; Wed, 4 Oct 2000 12:30:10 -0700 (PDT) X-Sun-Charset: US-ASCII Message-ID: <200010041930.e94JUAA00260@locked.eng.sun.com> Date: Wed, 4 Oct 2000 12:30:10 -0700 Reply-To: Mohan Parthasarathy Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mohan Parthasarathy Subject: Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "Mobility Support in IPv6" draft] X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > It seems that there are now multiple incompatible > interpretations of the specification within the > existing Internet Draft, that deals with making AH > computations when the Home Address option is present. > > I would like to mandate (i.e., MUST) the simplest possible > strategy, to wit: > > 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 Why do you say "might" here ? It is a bit confusing. > Source IP address field of the IPv6 header, and then the home > address would be in the Home Address destination option. > > Of course, this also means that the node receiving a packet > with AH will have to follow the same algorithm, which > basically just means not moving data fields at all. > The only complication comes when it is necessary to look up > the appropriate security association for processing either > AH or ESP. That lookup, typically indexed by the > Source IP address of the IPv6 header, would instead have > to be indexed by the home address in the Home Address > destination option. Since that destination option would > occur in the packet _before_ the security header, > processing is still very simple. > If you do it this way then other sections need change because currently the draft in section 5.4 talks about Home address option processing on receipt of a packet : ... on receipt of a packet with Home Address option, the receiving node replaces the Source Address in the IPv6 header with the Home Address in the Home Address option. I think there are other places. This tells me that the first thing i do is swap the addresses (or pointers ) and then do the AH computation. If this is correct and working out the transmit side based on this, you would need the following : 1) Insert a home address option with the CoA in it. 2) Do the IPsec processing (this includes SPD lookups which needs the right source address and hence gels in easily) 3) swap the addresses in the source field of the IPv6 header with the one in Home Address option after IPsec processing. We just have to describe the bits that pass through AH computation. Swapping is just a word to describe the contents of the home address option and the ipv6 source address field. This is no way modifying the contents of the packet. > My belief is that this is the simplest solution and makes > for a really unambiguous specification, promoting both > interoperability and ease of processing as well as better > compatibility with existing specifications for the order > of options processing. > Is the above ambiguous still ? Either way is fine by me as long as it is consistent. With your suggestion, you have to make sure that all sections that discusses about Home Address option processing is clear i.e AH before swap or swap before AH ? -mohan > Comments will be appreciated. A message which captures > a lot of the previous discussion is appended after the > main body of this note. In the appended discussion, the > question is raised whether a node receiving the Home Address > option can easily change the way it looks up the security > associations to depend on data in the Home Address option > instead of the IPv6 header. I have heard that this is > not a problem. I do not know the code myself, so I will > rely on input from others who have the appropriate experience. > > Regards, > Charlie P. > > > > > -------- Original Message -------- > Subject: Re: [MOBILE-IP] New version of "Mobility Support in IPv6" draft > Date: Sat, 23 Sep 2000 19:39:11 +0200 > From: Francis Dupont > To: charliep@iprg.nokia.com > CC: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > In your previous mail you wrote: > > My understanding is that the current specification makes it > mandatory to copy the home address into the ip6_src field of > the IPv6 header. Swapping should not be performed. Here, > "replace" means "copy over". I reckon that the current > specification should be made unequivocal on this point. > > => I disagree. You need to protect both the source address and > the address in the home address option (they should be the care-of > and the home addresses of the mobile). If you consider a common > binding update then you can see why this is important. > IMHO addresses must be swapped but there are two incompatible > ways to do this: > - swap field contents (easy, simple but some people don't like this) > - swap pointers (more difficult but keeps the packet read-only). > Someone must do the choice and write the result in the draft! > > ---- insert big logical break delimiter at this point --------- > > While thinking about the effects of this requirement, I found > myself wondering why. It seems like the natural processing > for the mobile node, when creating the Authentication Header, > would be to calculate the authentication data starting with > the predictable fields of the IPv6 header and extensions with > as little change as possible. > > => you should consider the receiving side for AH processing. > When the receiving side executes the home address option then > it updates the source address (the field itself (physical) and > the pointer to it (logical)). The AH is after then the source > address is supposed to be the home address when the AH is processed > and (the important point) when the security code looks for its > parameters. > > I would think that, typically, the IPv6 header already has the > mobile node's Care-of Address inserted as the ip6_src field before > the Authentication Header calculation is initiated. > > => it is not so clear and: > - the security parameters lookup (SPD/SADB) is more important than > the AH calculation itself and must be done with the home address. > - the AH calculation has to deal with mobility anyway. > > Then, in order to make the spec work, the mobile node has > to proceed as follows: > - Put in its home address as ip6_src, temporarily > - Do the AH thing > - Restore its care-of address as ip6_src. > This seems like a lot of extra work, and a very handy > place to put bugs. > > => AH calculation is in general a very handy place to put bugs. > Mobility doesn't make things worse, it just justifies we keep AH (:-). > > What if we make it so that the recipient uses the address > in the Home Address option to select the appropriate security > association? > > => this is an important point. The current spec makes this easy > for the recipient which: > - is the way AH processing is defined (cf routing header case) > - puts the burden on the mobile node shoulders > - works. > > I understand the current specification to be fashioned so that > the recipient can select the security association based on the > contents of the source IPv6 address in the IPv6 header. > However, whether or not to actually CHANGE the fields, > treating them as mutable, > > => swapping pointers is better for that (it was proposed by > Microsoft Research people who consider the packet as read-only) > > seems to introduce a lot of unnecessary specification difficulties > that could be avoided. > Changing the way that a security association is looked up > seems a lot cheaper than copying and recopying data within > the challenge data. > > => I am not convinced by your argument. In fact I am not convinced > by any argument for field or pointer swapping (:-)... Both are not > obviously right but this is a minor point: the real issue is to > deal with IKE (the draft proposal works, this is just a bit hard > to implement and very hard to configure). > > If everybody hates this idea, then just forget I mentioned it! > > => the only thing I really hate is to have no clear statement in > the current draft. It will make one half of secure mobile IPv6 > implementations not interoperable with mine... > > Thanks > > Francis.Dupont@enst-bretagne.fr > > PS: another missing point in the current mobile IPv6 draft: > the home agent is a router then can have more than one address then > the draft should *accurately* specify what address the home agent > MUST use as the source address of tunneled packet (the answer is > obvious but a specification is better than common sense, don't forget > a paranoid mobile node will check the source address of tunneled packets). > (the similar issue for BA/BR is already in the mailing list archive > because it simply breaks sequence number check) > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 17:19: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 RAA01932 for ; Wed, 4 Oct 2000 17:19:46 -0400 (EDT) Received: from standards (47.234.32.16:4433) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9CAFA@standards.nortelnetworks.com>; Wed, 4 Oct 2000 17:03:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20222 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 17:03:34 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9CAF8@standards.nortelnetworks.com>; Wed, 4 Oct 2000 16:53:33 -0400 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Wed Oct 4 17:07:29 EDT 2000 Received: from blhothuelpc (thuelpc [135.180.240.114]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id RAA03309; Wed, 4 Oct 2000 17:07:28 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <004501c02e46$e3f0a040$72f0b487@dnrc.belllabs.com> Date: Wed, 4 Oct 2000 17:05:57 -0400 Reply-To: Sandy Thuel Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Sandy Thuel Subject: Re: [MOBILE-IP] Are requirements required? X-To: Roberts Philip-qa3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit Hi Phil, > > In my mind, fast-handoff = micro-mobility. In your > > definition, fast handoff = (some mechanism based on > > Mobile IP) whereas micro-mobility = (some mechanism > > not based in Mobile IP). Is this correct? If so, > > can you explain what are the necessary conditions for > > a mechanism to be classified as being "based on > > Mobile IP"? This is too vague. > > > No this isn't correct. Well, the part about what's in your mind > is correct > I guess. Fast handoff can be done a number of ways. The mobile > IP working > group is working on it in the context of Mobile IP. If someone somewhere > has another way they want to do it that's fine and I think Pat > has said the > working group he's working on will be welcoming proposals. The > problem as I > see it is that Mobile IP as it's currently defined will have trouble > completing a "handoff" in time to keep from noticing a glitch in > service if > it's being used to support a realtime service. The efforts underway here > are an attempt to improve that situation. There is no question about the following statement you make regarding Mobile IP: > "as it's currently > defined will have trouble completing a "handoff" in > time to keep from noticing a glitch in service if > it's being used to support a realtime service." Some support for fast handoff (or however one wants to call it) is needed. The issue is: what qualifies a fast handoff solution to be considered to be "based on Mobile IP"? If it's clear to everyone in the world except for me, pardon me for my ignorance but I'd certainly appreciate if someone would take the time to spell this out for me. For example: Does "based on Mobile IP" mean "based on rfc 2002 (or its extensions)"? Does it mean "based exclusively on tunneling"? Sandy From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 17:26: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 RAA02150 for ; Wed, 4 Oct 2000 17:26:44 -0400 (EDT) Received: from standards (47.234.32.16:4433) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9CB12@standards.nortelnetworks.com>; Wed, 4 Oct 2000 17:05:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20223 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 17:05:33 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9CAF9@standards.nortelnetworks.com>; Wed, 4 Oct 2000 16:55:33 -0400 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Wed Oct 4 17:09:09 EDT 2000 Received: from blhothuelpc (thuelpc [135.180.240.114]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id RAA03336; Wed, 4 Oct 2000 17:09:09 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <004601c02e47$202c6530$72f0b487@dnrc.belllabs.com> Date: Wed, 4 Oct 2000 17:07:38 -0400 Reply-To: Sandy Thuel Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Sandy Thuel Subject: Re: [MOBILE-IP] Are requirements required? X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit Pat, Thanks for the update! Please keep us posted. Regards, Sandy > -----Original Message----- > From: pcalhoun@eng.sun.com [mailto:Pat.Calhoun@Eng.Sun.COM] > Sent: Tuesday, October 03, 2000 6:19 PM > To: Sandy Thuel > Cc: MOBILE-IP@standards.nortelnetworks.com > Subject: Re: [MOBILE-IP] Are requirements required? > > > > > > Pat's working hard to get a charter that the IESG is > > > happy with. > > > > I'm fully behind this. Is there somewhere where we > > can keep informed of the status of this effort without > > bugging Pat with email probes? > > > > My understanding is that the charter is now complete, and it is > scheduled for > the next IESG telechat. As soon as I hear anything, I will send > the info to > this list (and the craps list which will be renamed to follow the > new WG name). > PatC > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 17:56: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 RAA02741 for ; Wed, 4 Oct 2000 17:56:23 -0400 (EDT) Received: from standards (47.234.32.16:3418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9CBA0@standards.nortelnetworks.com>; Wed, 4 Oct 2000 17:40:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20433 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 17:40:05 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9CB9F@standards.nortelnetworks.com>; Wed, 4 Oct 2000 17:40:05 -0400 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 OAA21564; Wed, 4 Oct 2000 14:54:33 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e94LsUd27872; Wed, 4 Oct 2000 14:54:30 -0700 X-Virus-Scanned: Wed, 4 Oct 2000 14:54:30 -0700 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) smtpdrithS7; Wed, 04 Oct 2000 14:54:27 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <004501c02e46$e3f0a040$72f0b487@dnrc.belllabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39DBA715.C3D5EF5F@iprg.nokia.com> Date: Wed, 4 Oct 2000 14:54:29 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] Are requirements required? X-To: Sandy Thuel To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Sandy, > There is no question about the following statement > you make regarding Mobile IP: > > "as it's currently > > defined will have trouble completing a "handoff" in > > time to keep from noticing a glitch in service if > > it's being used to support a realtime service." I would like to raise a lot of doubt about this statement. There is nothing in Mobile IP that prevents the mobile node from knowing _EXACTLY_ when to register a new care-of address. There is nothing in Mobile IP that _ASSURES_ that the mobile node discovers exactly when to register a new care-of address. Mobile IP does NOT OFFER A SOLUTION for notifying the mobile node about the completely optimal time when to register a new care-of address. The solutions provided are not meant to stand in the way of any other better solution that might be available. A mobile node IS ALLOWED, by any means deemed expedient, to discover when to register a care-of address. This has a much different truth value than the quoted statement above. For example, suppose a mobile node hears an advertisement (from another protocol) 1000 times a second, that contains a care-of address, it will be able to execute perfectly smooth handovers. Just as an example. No one says you have to do it this way, and no one says you cannot do it this way. The protocol says you cannot issue RFC 1256 Router Advertisements this often, but nobody says you cannot do it another way. Bottom line is that a mobile node, using Mobile IP, _possibly_ but _not necessarily_ in conjunction with other protocols, _MAY_ be able to execute a perfectly smooth handover without any glitches. Maybe I didn't say this the right way or the politically correct way, but I hope it is clear. It's a little frustrating over the years to hear Mobile IP be so often dinged for not doing a thing it was explicitly designed to avoid doing. The whole point was to enable the development of link-specific or system-specific solutions since no general methods seem to be widely agreed upon as applicable. Link-specific and system-specific solutions have more limited interoperability, but that is just the way it is. > Some support for fast handoff (or however one wants > to call it) is needed. The issue is: what qualifies > a fast handoff solution to be considered to be > "based on Mobile IP"? If it's clear to everyone in > the world except for me, pardon me for my ignorance > but I'd certainly appreciate if someone would take > the time to spell this out for me. For example: > Does "based on Mobile IP" mean "based on rfc 2002 > (or its extensions)"? > Does it mean "based exclusively on tunneling"? These are questions that are very likely to receive intense scrutiny in the weeks to come. I don't mean to say whether the issues are clear, or not, but I would hope that the document resulting from the IPv6 design team's efforts will spell them out clearly for everyone's further comment. Clearly our outcomes will not necessarily be based on RFC 2002++. I do not think that approaches based on tunneling are excluded, but I don't know what the IPv6 team thinks. I also do not know whether the IPv4 drafts are reasonable for IPv6. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 18:03: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 SAA02891 for ; Wed, 4 Oct 2000 18:03:30 -0400 (EDT) Received: from standards (47.234.32.16:3418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9CBE4@standards.nortelnetworks.com>; Wed, 4 Oct 2000 17:46:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20431 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 17:46:05 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9CB9D@standards.nortelnetworks.com>; Wed, 4 Oct 2000 17:36:04 -0400 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA08428 for ; Wed, 4 Oct 2000 15:50:32 -0600 (MDT) 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 OAA20579; Wed, 4 Oct 2000 14:50:31 -0700 (PDT) Received: from sunray-mpke (sunray-mpke [129.146.6.32]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA21514; Wed, 4 Oct 2000 14:50:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: NbMwsVh4kjiurqLsUR/8BA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Message-ID: <200010042150.OAA21514@nasnfs.eng.sun.com> Date: Wed, 4 Oct 2000 14:50:31 -0700 Reply-To: Vipul Gupta Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Vipul Gupta Subject: Re: [MOBILE-IP] MIP implementation !!! X-To: xchr@INTRANET.GR To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM The folks behind the SUNY Binghamton implementation have moved on and that implementation is no longer maintained actively. If you are interested in something that works on Linux 2.2, you can try the distribution from Sun Labs at: http://playground.sun.com/~vgupta/sunlabs-mobileip-new.tar.gz regards, vipul p.s. If you are specifically looking for the Binghamton implementation, a copy can be found at http://playground.sun.com/pub/mobile-ip/Linux/Linux-MobileIPv101.tar.gz be warned, though, the last Linux kernel it was tested on is 1.3.58 (or thereabouts) and will not work on 2.2. Other Linux implementations are available from: o National University of Singapore (http://mip.ee.nus.sg/) o Stanford University as part of the Mosquitonet project (http://mosquitonet.stanford.edu/) > Good morning folks ! > Can someone please tell me whats going on with > the Binghamton UNIs URL for the Linux implementation > on Mobile IP? Its been for ages that Im trying to download > the files but it seems that the URL doesn't work anymore. > Does anyone know if they have any updated versions of the > implementation which runs on 2.2.x Kernells? > > Regards, > Christos > > -- > Christos Chrisanthakopoulos > > INTRACOM S.A. > Development Programmes Department > Panepistimiou 254 > 26443 Patras > GREECE > > Tel: (+30 61) 465153 (direct) > E-mail: xchr@intranet.gr > URL: www.intracom.gr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 19: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 TAA03935 for ; Wed, 4 Oct 2000 19:20:41 -0400 (EDT) Received: from standards (47.234.32.16:3418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9CD50@standards.nortelnetworks.com>; Wed, 4 Oct 2000 19:04:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20982 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 19:04:17 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:60670) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9CD4F@standards.nortelnetworks.com>; Wed, 4 Oct 2000 19:04:16 -0400 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 JAA20570 for ; Thu, 5 Oct 2000 09:16:02 +1000 (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 KAA20195 for ; Thu, 5 Oct 2000 10:18:14 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Oct 2000 10:18:23 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02E59.62C0BF60" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB31B@eaubrnt018.epa.ericsson.se> Date: Thu, 5 Oct 2000 10:18:21 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] Are requirements required? 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_01C02E59.62C0BF60 Content-Type: text/plain > I do not think that approaches based on tunneling are > excluded, but I don't know what the IPv6 team thinks. > I also do not know whether the IPv4 drafts are reasonable > for IPv6. > This is not so much in response to Charlie's statement but to other earlier ones. What I don't understand is why people keep relating MIP to tunnelling. Sorry if that sounds naive, but the association should be between MIP4 and tunnelling. Realistically speaking RO will probably not be used much in MIPv4 hence my statement. But for V6 why not ? Hopefully tunnelling will be minimised in V6. So if the assumption is that "MIP" = "MIPv4" then the association is correct but I wouldn't use that terminology anyway. There are 2 protocols here under the MIP umbrella. Regarding whether the V4 drafts are reasonabe for V6, I'll speak about Fast Handoffs. One of our main goals with Fast Handoffs was to find a solution that will work for both. Since the basic models of RFC 2002 and MIPv6 are similar, this shouldn't be too hard. So our approach was based on the model in RFC 2002 and you can see by reading both drafts (V4 and V6 Fast Handoffs) that they are very similar. So to answer the question, yes, I believe it's possible, and I'd like to maintain the model of RFC 2002 and MIPv6 as much as possible. ------_=_NextPart_001_01C02E59.62C0BF60 Content-Type: text/html RE: [MOBILE-IP] Are requirements required?

    I do not think that approaches based on tunneling are
    excluded, but I don't know what the IPv6 team thinks.
    I also do not know whether the IPv4 drafts are reasonable
    for IPv6.

    This is not so much in response to Charlie's statement but
    to other earlier ones.
    What I don't understand is why people keep relating MIP to
    tunnelling. Sorry if that sounds naive, but the association should
    be between MIP4 and tunnelling. Realistically speaking RO will
    probably not be used much in MIPv4 hence my statement.
    But for V6 why not ? Hopefully tunnelling will be minimised in V6.
    So if the assumption is that "MIP" = "MIPv4" then the association
    is correct but I wouldn't use that terminology anyway. There are 2
    protocols here under the MIP umbrella.

    Regarding whether the V4 drafts are reasonabe for V6, I'll speak
    about Fast Handoffs. One of our main goals with Fast Handoffs was
    to find a solution that will work for both. Since the basic models of
    RFC 2002 and MIPv6 are similar, this shouldn't be too hard.
    So our approach was based on the model in RFC 2002 and you can see
    by reading both drafts (V4 and V6 Fast Handoffs) that they are very similar.
    So to answer the question, yes, I believe it's possible, and I'd like to maintain
    the model of RFC 2002 and MIPv6 as much as possible.

------_=_NextPart_001_01C02E59.62C0BF60-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 05:19: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 FAA24049 for ; Thu, 5 Oct 2000 05:19:34 -0400 (EDT) Received: from standards (47.234.32.16:1860) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D0D7@standards.nortelnetworks.com>; Thu, 5 Oct 2000 5:02:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22133 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 05:02:44 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D0AD@standards.nortelnetworks.com>; Thu, 5 Oct 2000 4:52:43 -0400 Received: from vtnotes.victradco.com.tw ([203.65.167.34]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id EAA18461; Thu, 5 Oct 2000 04:07:01 -0500 (CDT) Received: from interscan.victradco.com.tw ([192.168.1.4]) by vtnotes.victradco.com.tw (Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) with SMTP id C825696E.0072A678; Thu, 5 Oct 2000 05:52:17 +0900 Received: from 209.179.196.180 by interscan.victradco.com.tw (InterScan E-Mail VirusWall NT) MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Message-ID: <0000351750cf$00007a96$000016f7@> Date: Wed, 4 Oct 2000 14:42:43 -0700 Reply-To: mcnab@SPRINTMAIL.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: mcnab@SPRINTMAIL.COM Subject: [MOBILE-IP] Fast Easy Cash 5879 X-To: Undisclosed.Recipients@hosaka.smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multipart message in MIME format --------------InterScan_NT_MIME_Boundary Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FREE Mortgage Quote

 HOMEOWNERS

 Do you want to pay off your credit card debt,
 refinance your existing mortgage, or take
 out additional cash for any purpose?

 WE SPECIALIZE IN FAST AND EASY APPROVALS

 * Borrow money even if you are in chapter 13 bankruptcy
  or save your home if you are facing foreclosure.
 * Pay off tax liens, judgments, or collection accounts.
 * Consolidate debts, pay bills.
 * Make home improvements, or even take that dream vacation.

 WE CAN GET YOU THE LOAN YOU NEED REGARDLESS OF YOUR CREDIT.

 * Good or Bad Credit OK * Self Employed OK
 * Prior Bankruptcy OK * Credit Problems OK

 Whatever your lifestyle needs. APPLY NOW! We can help.

 * WE FUND THE LOANS THAT OTHER LENDERS TURN DOWN!

 FOR A FAST, FREE LOAN QUOTE, FILL OUT THE FORM BELOW.



Our 60 second application

Fill= out this short form to receive your free information.
 All Questions Must Be Answered. Type NA To Those That Do Not Apply To You



.
First Name
Last Name
Co-Applicant's Name
City
State (abbreviation)
Street Address
Zip
Work Phone 000-000-0000
Home Phone 000-000-0000
Type of House Owned
Current Value
Purchase Price
First Mortgage Balance
Interest Rate
Fixed or Adjustable?
Monthly Payment
Behind on Payments?
How Would Your Rate Your Credit?
Place of Employment
Years There
Yearly Income
Best Time to Call
Type of Loan Desired
Email Address



If you received this in error or would like to be
removed from our list, PLEASE CLICK HERE

 

 

 

 

 

--------------InterScan_NT_MIME_Boundary-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 05:36: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 FAA24153 for ; Thu, 5 Oct 2000 05:36:51 -0400 (EDT) Received: from standards (47.234.32.16:1860) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D175@standards.nortelnetworks.com>; Thu, 5 Oct 2000 5:20:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22365 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 05:20:29 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D158@standards.nortelnetworks.com>; Thu, 5 Oct 2000 5:10:29 -0400 Received: from diginetserv01.diveo.com.ar ([200.51.67.51]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id EAA18559 for ; Thu, 5 Oct 2000 04:24:56 -0500 (CDT) Received: from cahsy3 (sdn-ar-001wimadiP152.dialsprint.net [158.252.99.88]) by diginetserv01.diveo.com.ar with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 42QY7296; Thu, 5 Oct 2000 05:47:31 -0300 X-Mailer: DiffondiCool V3,1,6,0 (W95/NT) (Build: Oct 18 1999) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: {923EE435-C7D6-11D3-92F6-004005A8672D}@cahsy3 Date: Tue, 11 Jan 2000 03:24:12 -0500 Reply-To: Patricia_Bo82@zahav.net.il Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patricia Subject: Re: [MOBILE-IP] Here Is The Information As Your Requested X-To: Patricia_95@zahav.net.il To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA24153 You were recently referred to me as someone who was ready for a CHANGE, a financial breakthrough, so I'll get right to the point. I am the one that can help you make $125,000 plus this year from HOME with your computer and phone. This is Not MLM and it IS very REAL. Are you Serious about making $2000 plus per week starting Right Away with a SIMPLE system where customers are contacting you and you do absolutely ZERO selling? Can you follow simple step-by-step instructions and put forth the effort to make this a reality for yourself starting today? If your answer is YES, then we need to talk. I have few positions available on my team and its in my best interest to train you for success. In fact, I'm so sure that I can do so, I'm willing to put my money where my mouth is! Upon accepting you as a member on my team, I will provide you with complete Professional Training and Advertising Assistance to put you immediately on the road to success. No experience necessary.... However you must have two qualities: moderate people skills and a serious desire for a personal and financial change. Take a moment to take the next step by calling me at my Home Office and I will get you the details. 1-800-570-4702 24 Hrs/ 7 Days Prosperous Regards! Patricia "Profits are better than wages. Wages make you a living; Profits make you a fortune" - Jim Rohn To be removed send email to ozzquer@yahoo.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 06:23: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 GAA24465 for ; Thu, 5 Oct 2000 06:23:05 -0400 (EDT) Received: from standards (47.234.32.16:1860) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D252@standards.nortelnetworks.com>; Thu, 5 Oct 2000 6:06:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22684 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 06:06:35 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D244@standards.nortelnetworks.com>; Thu, 5 Oct 2000 5:56:35 -0400 Received: from uci.agh.edu.pl (root@galaxy.uci.agh.edu.pl [149.156.96.9]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id FAA18759 for ; Thu, 5 Oct 2000 05:10:54 -0500 (CDT) Received: from saturn.kt.agh.edu.pl (proms@saturn.kt.agh.edu.pl [149.156.114.3]) by uci.agh.edu.pl (8.9.3/8.8.7/rchk1.20) with SMTP id MAA09520 for ; Thu, 5 Oct 2000 12:10:44 +0200 (MET DST) Received: by saturn.kt.agh.edu.pl (AIX 3.2/UCB 5.64/5.1) for mobile-ip@smallworks.com id AA19171; Thu, 5 Oct 2000 12:10:20 +0200 Address: Mickiewicza 30, 30-059 Krakow, POLAND Message-ID: <10010051010.AA19171@saturn.kt.agh.edu.pl> Date: Thu, 5 Oct 2000 12:10:20 +0200 Reply-To: Piotr Pacyna Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Piotr Pacyna Organization: University of Mining and Metallurgy Subject: [MOBILE-IP] PROMS2000: Call for Participation X-To: mobile-ip@smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM We do apologize, if you receive multiple copies of this e-mail --------------------------------------------------------------------- PROTOCOLS FOR MULTIMEDIA SYSTEMS - PROMS2000 CALL FOR PARTICIPATION Cracow, Poland, October 22-25, 2000 http://PROMS2000.kt.agh.edu.pl/ PRELIMINARY CONFERENCE PROGRAMME Monday, 23 October 2000 08:30-09:50 Registration 09:50-10:00 Opening 10:00-11:30 Tutorial Stefan Arbanowski, Sven van den Meyer, Technical University Berlin, Germany Flexible media and content adaptation for Communication Systems 11:50-13:20 Tutorial Johan Zuidweg, Tecsidel S.A., Spain Software architectures for Next Generation Networks 14:50-16:10 Session 1A - Multimedia Protocols SIGTRAN: Signaling Transport A Relative Differentiated Service Model for Adaptive Traffic Decreasing Transfer Delay Through Partial Reliability Issues about Advance Reservation for Real-Time Traffic 14:50-16:10 Session 1B: IP-Based Services Virtual Broadcast - A novel service based on IP Multicast Scalable Resource Management Architecture for VoIP Unicast Extensions to IP Multicast 16:30-18:00 Tutorial Stanislaw Jedrus, Polish Academy of Science, Poland Practical introduction to multimedia traffic characterization and modelling techniques Tuesday, 24 October 2000 9:00-10:30 Tutorial Oliver Verscheure, IBM T.J. Watson Laboratory Scalable Multi-Windowed DTV Experience 11:50-13:00 Session 2A: QoS Management A Reflective Component-Based Middleware with Quality of Service Management QoS measurements and comparative analysis of performance parameters on ISPs Quality of Service for TCP/IP Traffic: An Overview Flexible and Extensible QoS-Management for Adaptive Middleware An Integrated Toolset for the Design of Protocols with QoS Requirements (ProtCAD/RT) Adaptability in multimedia transmissions using layering multicast and QoS guarantees 11:50-13:00 Session 2B: Video Streaming Performance Streaming Multimedia Data with Adaptive QoS Characteristics Transmission of MPEG Video over Networks with Closed-Loop Rate-Based Flow Control Buffering at Internet Caches for Improving QoS of Streaming Media Solid State Disks in Multimedia Systems with Deterministic QoS Quality Control Experiences in on Demand Video Transmission Video Placement on a Networked Disk Subsystem for Clustered Video-on-Demand Servers 14:50-16:10 Session 3A: QoS Provisioning A Framework for on-Demand QoS Bearers over Fixed and Mobile Internet Access Protocol or Header Indication - Methods to Request Quality of Service for IP-Apps Inter-domain QoS provision for Internet-wide multicast traffic SR-QoS System for Multimedia Communication in Mobile Ad Hoc Networks 14:50-16:10 Session 3B: Media Streaming Architectures An Architecture for Streaming Control in Distributed Multimedia Systems Video on Demand Using HTTP DiVA: QoS-aware streaming of multimedia content over the Internet Reliable and Flexible Video Codec Structure Implemented on a RISC Processor 20:00 Banquet Wednesday, 25 October 2000 8:30-10:00 Tutorial Peter Psenak, Cisco Systems, Belgium MPLS Traffic Engineering 10:30-11:50 Session 4A: Service Access Copyright Protection Protocols for Multimedia Distribution Based on Trusted Hardware Broadband Network Set-Top Box System Virtual Collaborative Environment with Next Generation Multimedia Systems Design and Implementation of the Electronic Programme Guides for the MPEG2-Based DVB 10:30-11:50 Session 4B: Traffic Engineering Analysis of the Adaptive Rate Control for Point to Multipoint Connections in ATM Nets Modeling and Performance Evaluation of an HFC Network Operator Deficit Round Robin Alternated: A New Scheduling The Performance of Multiplexing Voice and Circuit Switched Data in UMTS over IP Network 11:50-13:00 Session 5A - Poster: Networking Issues Group Signature Schemes Based on the Difficulty of Computation of Approximate E-th Root Internet Card, a smart card for internet Influence of Intervals and Packet Length in Test Sequences - Limits of Testing Enhanced Distributed recording of Mbone sessions Mobility in ATM Networks - QoS Support in Handover Protocols 11:50-13:00 Session 5B - Poster: Media Retrieval Methods for Content Based Radiological Images Searching Integration of a Voice Recognition-Based Indexing with Multimedia Applications Towards a High Level Interface for Content Based Retrieval and Querying Selfsimilarity of an MPEG-2 Video Stream Generated by DVD Applications 14:50-16:10 Session 6A: Service Access The Problem of End-to-end Security for Proxy-based Systems IGMPv3 Extensions for Providing IP Multicast Authentication Services: An Example of DoS Multicast Attacks Avoidance Monitoring Extensions for Component-Based Distributed Software 14:50-16:10 Session 6B: Traffic Engineering Effects of Red Dynamics on TCP-Friendliness of Rate-Based Control Protocol Multimedia Signals over IP by Using Polyphase Down Sampling Multiple Description SDL Based Performance Analysis of Audio over ST2+ Fine Grained Rate Control at Network Edge Nodes ------------------------------------------------------ see http://PROMS2000.kt.agh.edu.pl/ Thank you. ------------------------------------------------------ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 08:16: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 IAA27212 for ; Thu, 5 Oct 2000 08:16:58 -0400 (EDT) Received: from standards (47.234.32.16:2087) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D346@standards.nortelnetworks.com>; Thu, 5 Oct 2000 8:00:31 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23017 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 08:00:31 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D345@standards.nortelnetworks.com>; Thu, 5 Oct 2000 8:00:28 -0400 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 e95CEWs53917; Thu, 5 Oct 2000 14:14:32 +0200 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 OAA29537; Thu, 5 Oct 2000 14:14:31 +0200 (MET DST) 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 OAA98905; Thu, 5 Oct 2000 14:17:45 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200010051217.OAA98905@givry.rennes.enst-bretagne.fr> Date: Thu, 5 Oct 2000 14:17:45 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] Proposal for new Destination Options placement X-To: "Charles E. Perkins" X-cc: Francis Dupont , IPng Working Group To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Wed, 04 Oct 2000 08:11:13 PDT. <39DB4891.4D00FE56@iprg.nokia.com> In your previous mail you wrote: I agree with you that the existing choices for ordering AH and Destination Options are not sufficient. In my mind, the first and most serious error, that affects the placement of the Home Address option, is it has to go before AH, but there is no need at all for it to be processed by the intermediate routing points of a routing header. Therefore, I'd like to suggest that in the Mobile IPv6 specification, we enable the placement of Destination Options after the Routing Header, but before the Fragment Header. This will enable the correct placement of the Home Address destination option, and it will greatly simplify any needed firewall treatment. => we agree. We'll get three kinds of destination options extension headers: - "note 1" which are not used (IMHO we should garbage collected them). - new DO headers between the routing header (if any) and the fragmentation header (if any). I believe the tunnel encapsulation limit should go there too (ie. with the home address option) because this will limit over-encapsulated fragments (and over-encapsulation would produce fragments). - "note 3" well known DO headers which will be used today only for binding options then should get a new value for its next-header type (this will not introduce major interoperability problems and will make things far simpler to understand ans to implement). Thanks Francis.Dupont@enst-bretagne.fr PS: this mail is the result of a meeting at IPv6 bake-off organized by ETSI between all present mobile IPv6 gurus... From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 08:46: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 IAA27793 for ; Thu, 5 Oct 2000 08:46:09 -0400 (EDT) Received: from standards (47.234.32.16:2087) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D3AD@standards.nortelnetworks.com>; Thu, 5 Oct 2000 8:29:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23149 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 08:29:36 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D3AC@standards.nortelnetworks.com>; Thu, 5 Oct 2000 8:29:35 -0400 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 e95Chws17643; Thu, 5 Oct 2000 14:43:58 +0200 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 OAA00268; Thu, 5 Oct 2000 14:43:57 +0200 (MET DST) 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 OAA99032; Thu, 5 Oct 2000 14:47:11 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200010051247.OAA99032@givry.rennes.enst-bretagne.fr> Date: Thu, 5 Oct 2000 14:47:11 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] Implementation Issues re MobileIP and IPSec] X-To: "Charles E. Perkins" X-cc: Francis Dupont To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Wed, 04 Oct 2000 08:15:32 PDT. <39DB4994.A9A0645A@iprg.nokia.com> In your previous mail you wrote: The Binding Update, as you and others have mentioned, could reasonably go either in the same Destination Options header as the Home Address option, or after AH. It seems to be a matter of convenience. The Binding Update option seems to have less needs for protection against snooping than the IPv6 header. In other words, if one wanted to protect the Binding Update, then one would also want to protect the preceding IPv6 header. That implies to me that the main good reason for requiring the Binding Update to go after AH, except possibly for natural processing requirements. On the other hand, the latter is a good reason! => this argument (natural processing) was shared by a majority of the people here at ETSI bake-off (ie. most of us would like to execute the binding update when the option is found then it must be after the home address option and the authentication header, according to mobile IPv6 + IPsec requirements this gives exactly the "note 3" position, ie. after IPsec headers (including the required AH)). I do see that we should make a definite specification for particular placement of the Binding Update. => and use the same for other binding options ("previous" draft is not enough accurate about this then we have this discussion). I would like to make the following proposal for discussion. - Allow Home Address option to be placed after the routing header but before the fragment header (as mentioned earlier) - Require Binding Update to occur after AH. => this is good for us. The cost is additional header bytes, but the benefit is more natural header processing. I think that we ought to get this issue settled ASAP, with a specific placement, and then try to get some mileage out of using header compression to squeeze the bytes back out again. Using header compression might be more efficient if there are fewer possibilities for placement. => anything is simpler and more efficient with fewer possibilities. Obviously the "previous" draft has too much freedom there... Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 09:22: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 JAA28489 for ; Thu, 5 Oct 2000 09:22:55 -0400 (EDT) Received: from standards (47.234.32.16:2087) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D449@standards.nortelnetworks.com>; Thu, 5 Oct 2000 9:06:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23355 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 09:06:25 -0400 Received: from odin2.bull.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D448@standards.nortelnetworks.com>; Thu, 5 Oct 2000 9:06:25 -0400 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 PAA38994; Thu, 5 Oct 2000 15:25:43 +0200 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 PAA20416; Thu, 5 Oct 2000 15:20:02 +0200 Received: from bull.net (localhost [127.0.0.1]) by isatis.frec.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id PAA130126; Thu, 5 Oct 2000 15:19:56 +0200 (DFT) X-Mailer: Mozilla 4.06 [en] (X11; I; AIX 4.2) MIME-Version: 1.0 References: <39DB6C48.8D2BE6E2@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39DC7FFB.9F5B9D1F@bull.net> Date: Thu, 5 Oct 2000 15:19:55 +0200 Reply-To: Aime.Le-Rouzic@BULL.NET Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: AIme Le-Rouzic Organization: Bull Subject: Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "Mobility Support in IPv6" draft] X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, Charles E. Perkins 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. The RH used towards the mobile and the Destination Option Home address are similar about many aspects. Can't we have the same behavior about AH for both. To authenticate the RH the AH processing is done on the state RH will be at the reception.That means the Home Address in the IP header. The Home address in the IP header is the final state of the packet also when HA, it is why it may be better to apply AH on this state. Best Regards. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 09:31: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 JAA28625 for ; Thu, 5 Oct 2000 09:31:52 -0400 (EDT) Received: from standards (47.234.32.16:2087) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D498@standards.nortelnetworks.com>; Thu, 5 Oct 2000 9:15:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23458 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 09:15:20 -0400 Received: from auemail2.firewall.lucent.com (auemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D497@standards.nortelnetworks.com>; Thu, 5 Oct 2000 9:15:19 -0400 Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA04110 for ; Thu, 5 Oct 2000 09:29:50 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA04097 for ; Thu, 5 Oct 2000 09:29:49 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Oct 2000 14:29:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04877320@en0060exch001u.uk.lucent.com> Date: Thu, 5 Oct 2000 14:29:35 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM While I'm waiting for answers, I'll go further, hoping the backlog won't increase too much: It seems to me that in case some policies are related to QoS, then a QoS client is better suited than a MIP client. maybe we could define MIP QoS extensions that could be used by (that is are compatible with) the COPS RSVP client (just as a dumb example). If instead you are talking about roaming policies, then probably they could naturally fit within the AAA framework. Any user profile can also be downloaded to a PEP (which does not necessarily speak COPS) when the user registers and as such the home AAA server is queried. This is somehow consistent with the HSS model... The envelope of such profiles may not be COPS. It may be part of the AAA protocol (more usefully, I think) For other "service specific" policy, again, the MIP extensions possibly should be defined so that they could be used by the client for that specific service. alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 11:38: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 LAA01377 for ; Thu, 5 Oct 2000 11:38:06 -0400 (EDT) Received: from standards (47.234.32.16:2087) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D700@standards.nortelnetworks.com>; Thu, 5 Oct 2000 11:20:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24267 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 11:20:59 -0400 Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D6FF@standards.nortelnetworks.com>; Thu, 5 Oct 2000 11:20:58 -0400 Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA24320 for ; Thu, 5 Oct 2000 11:35:29 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA24245 for ; Thu, 5 Oct 2000 11:35:26 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Oct 2000 16:35:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04877324@en0060exch001u.uk.lucent.com> Date: Thu, 5 Oct 2000 16:35:20 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt X-To: Muhammad Jaseemuddin X-cc: Abderrahmane Lakas To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > It seems to me that in case some policies are related > to QoS, then a QoS client is better suited than a MIP client. > maybe we could define MIP QoS extensions that could be used by > (that is are compatible with) the COPS RSVP client (just as a dumb > example). > > [MJ] You are very close to what has motivated us > Cool! > . Yes, we can define some MIP extension for QoS, but where that extension > will be processed? Most likely at PDP. For that, we need to communicate > that QoS extension to the PDP. We can do that using COPS-MIP. > Or COPS RSVP if we are smart enough to reuse work done by others... > I am glad that you mentioned COPS-RSVP. Because, that helps > understand COPS-MIP as it is analogous to COPS-RSVP. They both use the > same COPS signaled policy model. However COPS-RSVP is designed to > understand and handle RSVP objects. In order to handle MIP extensions, we > need a new COPS client that understands and handle MIP extensions. That's > what we think COPS-MIP is for. > I would regard COPS MIP as useful as COPS IP. The fact a user is moving should not affect policy mechanisms. > If instead you are talking about roaming policies, then probably > they > could naturally fit within the AAA framework. > Any user profile can also be > downloaded to a PEP (which does not necessarily speak COPS) when > the user registers and as such the home AAA server is queried. > This is somehow consistent with the HSS model... > The envelope of such profiles may > not be COPS. It may be part of the AAA protocol (more usefully, I think) > > [MJ] Yes the roaming policies are most likely handled by AAA > server, and if the PDP needs information about them, then the PDP can > communicate with the AAA server. But, whichever mechanisms are used to > handle roaming policies, should not affect COPS-MIP. > If COPS MIP won't exist, as I personally think, this is going to be most likely. > For other "service specific" policy, again, the MIP extensions > possibly should be defined so that they could be used by the > client for that specific service. > > [MJ] Which client? If you are talking about COPS client, then that > is COPS-MIP. > > Oh well, If I talk about host routing, somebody thinks I talking about CIP If I talk about a COPS client, somebody thinks it is the COPS MIP client... Please, try not to limit your perspective to the work you have done (which is pointing out some aspects people could work on, but probably it is not the best possible solution). having said that, I'm still waiting some answers from the backlog (there's one on authentication handling I'm particularly keen on) Alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 11:38: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 LAA01382 for ; Thu, 5 Oct 2000 11:38:13 -0400 (EDT) Received: from standards (47.234.32.16:2087) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D707@standards.nortelnetworks.com>; Thu, 5 Oct 2000 11:21:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24270 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 11:21:14 -0400 Received: from zrtps06u.us.nortel.com (47.140.48.52:43727) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D704@standards.nortelnetworks.com>; Thu, 5 Oct 2000 11:21:13 -0400 Received: from qhars002.nortel.com (zhars00t.europe.nortel.com [47.101.112.102]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id e95FZfL16956 for ; Thu, 5 Oct 2000 11:35:41 -0400 (EDT) Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com; Thu, 5 Oct 2000 16:17:59 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Thu, 5 Oct 2000 10:12:47 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 5 Oct 2000 10:16:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02EDF.384F9C20" X-Orig: Message-ID: Date: Thu, 5 Oct 2000 10:16:22 -0500 Reply-To: Muhammad Jaseemuddin Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Muhammad Jaseemuddin Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt X-To: "Casati, Alessio (Alessio)" X-cc: Abderrahmane Lakas 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_01C02EDF.384F9C20 Content-Type: text/plain Alessio: See my comments in-line. > -----Original Message----- > From: Casati, Alessio (Alessio) [SMTP:acasati@LUCENT.COM] > Sent: Thursday, October 05, 2000 9:30 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] FW: I-D > ACTION:draft-jaseem-rap-cops-mip-00.txt > > While I'm waiting for answers, > I'll go further, hoping the backlog won't > increase too much: > > It seems to me that in case some policies are related > to QoS, then a QoS client is better suited than a MIP client. > maybe we could define MIP QoS extensions that could be used by > (that is are compatible with) the COPS RSVP client (just as a dumb > example). > [MJ] You are very close to what has motivated us. Yes, we can define some MIP extension for QoS, but where that extension will be processed? Most likely at PDP. For that, we need to communicate that QoS extension to the PDP. We can do that using COPS-MIP. I am glad that you mentioned COPS-RSVP. Because, that helps understand COPS-MIP as it is analogous to COPS-RSVP. They both use the same COPS signaled policy model. However COPS-RSVP is designed to understand and handle RSVP objects. In order to handle MIP extensions, we need a new COPS client that understands and handle MIP extensions. That's what we think COPS-MIP is for. > If instead you are talking about roaming policies, then probably they > could naturally fit within the AAA framework. > Any user profile can also be > downloaded to a PEP (which does not necessarily speak COPS) when > the user registers and as such the home AAA server is queried. > This is somehow consistent with the HSS model... > The envelope of such profiles may > not be COPS. It may be part of the AAA protocol (more usefully, I think) > [MJ] Yes the roaming policies are most likely handled by AAA server, and if the PDP needs information about them, then the PDP can communicate with the AAA server. But, whichever mechanisms are used to handle roaming policies, should not affect COPS-MIP. > For other "service specific" policy, again, the MIP extensions > possibly should be defined so that they could be used by the > client for that specific service. > [MJ] Which client? If you are talking about COPS client, then that is COPS-MIP. > alessio ------_=_NextPart_001_01C02EDF.384F9C20 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] FW: I-D = ACTION:draft-jaseem-rap-cops-mip-00.txt

    Alessio:

    See my comments = in-line.


    -----Original Message-----
    From:   Casati, Alessio (Alessio) = [SMTP:acasati@LUCENT.COM]
    Sent:   Thursday, October 05, 2000 9:30 AM
    To:     MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: [MOBILE-IP] FW: I-D = ACTION:draft-jaseem-rap-cops-mip-00.txt

    While I'm waiting for answers,
    I'll go further, hoping the backlog = won't
    increase too much:

    It seems to me that in case some = policies are related
    to QoS, then a QoS client is better = suited than a MIP client.
    maybe we could define MIP QoS = extensions that could be used by
    (that is are compatible with) the = COPS RSVP client (just as a dumb example).

    [MJ]  You are very close to what has motivated us. = Yes, we can define some MIP extension for QoS, but where that extension = will be processed? Most likely at PDP. For that, we need to communicate = that QoS extension to the PDP. We can do that using COPS-MIP.  =

    I am glad that you = mentioned COPS-RSVP. Because, that helps understand COPS-MIP as it is = analogous to COPS-RSVP. They both use the same COPS signaled policy = model. However COPS-RSVP is designed to understand and handle RSVP = objects. In order to handle MIP extensions,  we need a new COPS = client that understands and handle MIP extensions. That's what we think = COPS-MIP is for.


    If instead you are talking about = roaming policies, then probably they
    could naturally fit within the AAA = framework.
    Any user profile can also be
    downloaded to a PEP (which does not = necessarily speak COPS) when
    the user registers and as such the = home AAA server is queried.
    This is somehow consistent with the = HSS model...
    The envelope of such profiles = may
    not be COPS. It may be part of the = AAA protocol (more usefully, I think)

    [MJ]  Yes the roaming policies are most likely = handled by AAA server, and if the PDP needs information about them, = then the PDP can communicate with the AAA server. But, whichever = mechanisms are used to handle roaming policies, should not affect = COPS-MIP.

    For other "service specific" = policy, again, the MIP extensions
    possibly should be defined so that = they could be used by the
    client for that specific = service.

    [MJ]  Which client? If you are talking about COPS = client, then that is COPS-MIP.



    alessio

------_=_NextPart_001_01C02EDF.384F9C20-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 11:48: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 LAA01677 for ; Thu, 5 Oct 2000 11:48:14 -0400 (EDT) Received: from standards (47.234.32.16:2087) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D773@standards.nortelnetworks.com>; Thu, 5 Oct 2000 11:27:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24263 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 11:27:34 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D6FB@standards.nortelnetworks.com>; Thu, 5 Oct 2000 11:17:30 -0400 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Thu Oct 5 11:31:54 EDT 2000 Received: from blhothuelpc (thuelpc [135.180.240.114]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id LAA15505; Thu, 5 Oct 2000 11:31:53 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <005301c02ee1$2d3f3410$72f0b487@dnrc.belllabs.com> Date: Thu, 5 Oct 2000 11:30:22 -0400 Reply-To: Sandy Thuel Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Sandy Thuel Subject: Re: [MOBILE-IP] Are requirements required? X-To: charliep@iprg.nokia.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <39DBA715.C3D5EF5F@iprg.nokia.com> Content-Transfer-Encoding: 7bit Hi Charlie, > > > There is no question about the following statement > > you make regarding Mobile IP: > > > "as it's currently > > > defined will have trouble completing a "handoff" in > > > time to keep from noticing a glitch in service if > > > it's being used to support a realtime service." > > I would like to raise a lot of doubt about this statement. > > There is nothing in Mobile IP that prevents the mobile > node from knowing _EXACTLY_ when to register a new > care-of address. > > There is nothing in Mobile IP that _ASSURES_ that the > mobile node discovers exactly when to register a new > care-of address. > > Mobile IP does NOT OFFER A SOLUTION for notifying > the mobile node about the completely optimal time > when to register a new care-of address. The solutions > provided are not meant to stand in the way of any other > better solution that might be available. > > A mobile node IS ALLOWED, by any means deemed expedient, > to discover when to register a care-of address. > > This has a much different truth value than the quoted > statement above. > > For example, suppose a mobile node hears an advertisement > (from another protocol) 1000 times a second, that contains > a care-of address, it will be able to execute perfectly > smooth handovers. Just as an example. No one says you > have to do it this way, and no one says you cannot do > it this way. The protocol says you cannot issue RFC 1256 > Router Advertisements this often, but nobody says you > cannot do it another way. > > Bottom line is that a mobile node, using Mobile IP, > _possibly_ but _not necessarily_ in conjunction with > other protocols, _MAY_ be able to execute a perfectly > smooth handover without any glitches. > > Maybe I didn't say this the right way or the politically > correct way, but I hope it is clear. It's a little > frustrating over the years to hear Mobile IP be so often > dinged for not doing a thing it was explicitly designed > to avoid doing. The whole point was to enable the > development of link-specific or system-specific solutions > since no general methods seem to be widely agreed upon > as applicable. Link-specific and system-specific solutions > have more limited interoperability, but that is just the > way it is. Thanks for your clarifications regarding Mobile IP's ability to support fast handoffs and sorry for having quoted such a mis-leading statement. I absolutely agree that there is nothing inherent in Mobile IP that prevents or precludes fast handoff support. It is also clear that Mobile IP was designed with no assumptions nor requirements about specific link-layer mechanisms for fast handoffs (e.g., informing the mobile exactly when to register a new care-of-address). On the other hand, the judicious exploitation of link-layer support for fast handoffs, when such support exists, has the potential to significantly enhance the handover performance of Mobile IP. The challenge is in findings ways to exploit these mechanisms without violating the link-layer transparency of Mobile IP's design. By the same token, the fine-tuning of performance parameters for mechanisms defined by Mobile IP (e.g., frequency of router advertisements) can also help in enhancing handover performance (without exploiting any link-layer support). There are, however, cost/performance tradeoffs for these different approaches that aren't obvious (to me, at least). I would expect that the WG work on fast handoff support would shed some light on these tradeoffs. > > > Some support for fast handoff (or however one wants > > to call it) is needed. The issue is: what qualifies > > a fast handoff solution to be considered to be > > "based on Mobile IP"? If it's clear to everyone in > > the world except for me, pardon me for my ignorance > > but I'd certainly appreciate if someone would take > > the time to spell this out for me. For example: > > Does "based on Mobile IP" mean "based on rfc 2002 > > (or its extensions)"? > > Does it mean "based exclusively on tunneling"? > > These are questions that are very likely to receive > intense scrutiny in the weeks to come. I don't mean > to say whether the issues are clear, or not, but I would > hope that the document resulting from the IPv6 design > team's efforts will spell them out clearly for > everyone's further comment. Clearly our outcomes > will not necessarily be based on RFC 2002++. > It's comforting to hear that these questions will be addressed in more depth. Do you know what is the IPv6 design team's target timeframe in making this document available? Is there any place where people external to the design team can keep tabs on the team's progress? Regards, Sandy From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 11:59: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 LAA02021 for ; Thu, 5 Oct 2000 11:59:36 -0400 (EDT) Received: from standards (47.234.32.16:2087) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D842@standards.nortelnetworks.com>; Thu, 5 Oct 2000 11:37:47 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24674 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 11:37:47 -0400 Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D841@standards.nortelnetworks.com>; Thu, 5 Oct 2000 11:37:47 -0400 Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA15887 for ; Thu, 5 Oct 2000 11:52:17 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA15856 for ; Thu, 5 Oct 2000 11:52:17 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Oct 2000 16:52:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04877325@en0060exch001u.uk.lucent.com> Date: Thu, 5 Oct 2000 16:52:05 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] Are requirements required? X-To: Sandy Thuel To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > It's comforting to hear that these questions will be > addressed in more depth. Do you know what is the > IPv6 design team's target timeframe in making this > document available? Is there any place where people > external to the design team can keep tabs on the > team's progress? > > Regards, > Sandy > > > > A discussion list has been setup for this and the address > of this list > > is: mipv6-handoff@sunroof.eng.sun.com > > > > The list is open to anyone who wishes to contribute to this > effort and > > anyone can be a part of the design team. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 12:11: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 MAA02258 for ; Thu, 5 Oct 2000 12:11:27 -0400 (EDT) Received: from standards (47.234.32.16:2087) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D8CB@standards.nortelnetworks.com>; Thu, 5 Oct 2000 11:45:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24650 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 11:45:53 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D82B@standards.nortelnetworks.com>; Thu, 5 Oct 2000 11:35:53 -0400 Received: from 209.162.52.130 (209-162-52-130.thegrid.net [209.162.52.130]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id KAA20303; Thu, 5 Oct 2000 10:50:12 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <00003f147f89$00002545$00002cee@209.162.52.130> Date: Thu, 5 Oct 2000 07:54:33 -0700 Reply-To: gusremove@canada.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: marc489@EXCITE.COM Subject: [MOBILE-IP] E-mail for your businness X-To: Undisclosed.Recipients@hosaka.smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: quoted-printable
Whether You Are Looking For Sales, Leads or Exposure,
we offer targeted or general e-mails
with current, fresh email addresses.

We GUARANTEE response !

Now you can afford to advertise!

SUMMER SPECIAL!!!
Call us to send 100,000 emails and we will send
an additional 100,000 for free, using our special
targeted e-mail list.

Speical rates end Oct./10/00

* We can assist you in developing your entire campaign!

* We can even create your ad or annoucement for you!


CALL NOW - 702-876-4334 ask for Gus



For removal see below.





++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Sorry if you received this message in error.
If you wish to be removed. Please, type "REMOVE"
in the subject line:MAILTO: gusremove.canada.com
++++++++++++++++++++++++++++++++++++++++++++++++++++++++


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 12:24: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 MAA02545 for ; Thu, 5 Oct 2000 12:24:49 -0400 (EDT) Received: from standards (47.234.32.16:2087) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D98E@standards.nortelnetworks.com>; Thu, 5 Oct 2000 12:08:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25062 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 12:08:07 -0400 Received: from 209.162.52.130 (209-162-52-130.thegrid.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D96C@standards.nortelnetworks.com>; Thu, 5 Oct 2000 11:58:06 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <00003f147f89$00002545$00002cee@209.162.52.130> Date: Thu, 5 Oct 2000 07:54:33 -0700 Reply-To: gusremove@canada.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: marc489@EXCITE.COM Subject: [MOBILE-IP] E-commerce, is it for you? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: quoted-printable
Whether You Are Looking For Sales, Leads or Exposure,
we offer targeted or general e-mails
with current, fresh email addresses.

We GUARANTEE response !

Now you can afford to advertise!

SUMMER SPECIAL!!!
Call us to send 100,000 emails and we will send
an additional 100,000 for free, using our special
targeted e-mail list.

Speical rates end Oct./10/00

* We can assist you in developing your entire campaign!

* We can even create your ad or annoucement for you!


CALL NOW - 702-876-4334 ask for Gus



For removal see below.





++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Sorry if you received this message in error.
If you wish to be removed. Please, type "REMOVE"
in the subject line:MAILTO: gusremove.canada.com
++++++++++++++++++++++++++++++++++++++++++++++++++++++++



Whethe= r You Are Looking For Sales, Leads or Exposure,

we offer targeted = or general e-mails

with current, fresh email addresses.


=

From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 12:24: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 MAA02549 for ; Thu, 5 Oct 2000 12:24:50 -0400 (EDT) Received: from standards (47.234.32.16:2087) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D9A2@standards.nortelnetworks.com>; Thu, 5 Oct 2000 12:09:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25124 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 12:09:14 -0400 Received: from zrtps06u.us.nortel.com (47.140.48.52:47731) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D9A1@standards.nortelnetworks.com>; Thu, 5 Oct 2000 12:09:09 -0400 Received: from qhars002.nortel.com (zhars00t.europe.nortel.com [47.101.112.102]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id e95GNdL27915 for ; Thu, 5 Oct 2000 12:23:39 -0400 (EDT) Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Thu, 5 Oct 2000 17:23:01 +0100 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Thu, 5 Oct 2000 11:20:12 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 5 Oct 2000 11:20:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02EE8.1BE97930" Message-ID: <36FA02BD7083D411BC9E0000F8073E438CEEB7@crchy271.us.nortel.com> Date: Thu, 5 Oct 2000 11:20:00 -0500 Reply-To: Glenn Morrow Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Glenn Morrow Subject: Re: [MOBILE-IP] Are requirements required? X-To: "Casati, Alessio (Alessio)" 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_01C02EE8.1BE97930 Content-Type: text/plain I believe December is the timeframe. Here is how to subscribe: TO: 'Majordomo@sunroof.eng.sun.com' BODY: subscribe mipv6-handoff@sunroof.eng.sun.com "address" > -----Original Message----- > From: Casati, Alessio (Alessio) [SMTP:acasati@LUCENT.COM] > Sent: Thursday, October 05, 2000 10:52 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Are requirements required? > > > It's comforting to hear that these questions will be > > addressed in more depth. Do you know what is the > > IPv6 design team's target timeframe in making this > > document available? Is there any place where people > > external to the design team can keep tabs on the > > team's progress? > > > > Regards, > > Sandy > > > > > > > A discussion list has been setup for this and the address > > of this list > > > is: mipv6-handoff@sunroof.eng.sun.com > > > > > > The list is open to anyone who wishes to contribute to this > > effort and > > > anyone can be a part of the design team. ------_=_NextPart_001_01C02EE8.1BE97930 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] Are requirements required?

I believe December = is the timeframe.

Here is how to = subscribe:

TO:
'Majordomo@sunroof.eng.sun.com'

BODY:
subscribe = mipv6-handoff@sunroof.eng.sun.com "address"

    -----Original Message-----
    From:   Casati, Alessio (Alessio) = [SMTP:acasati@LUCENT.COM]
    Sent:   Thursday, October 05, 2000 10:52 AM
    To:     MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: [MOBILE-IP] Are requirements = required?

    > It's comforting to hear that = these questions will be
    > addressed in more depth.  = Do you know what is the
    > IPv6 design team's target = timeframe in making this
    > document available? Is there any = place where people
    > external to the design team can = keep tabs on the
    > team's progress?
    >
    > Regards,
    > Sandy
    >
    >
    > > A discussion list has been = setup for this and the address
    > of this list
    > > is: = mipv6-handoff@sunroof.eng.sun.com
    > >
    > > The list is open to anyone = who wishes to contribute to this
    > effort and
    > > anyone can be a part of the = design team.

------_=_NextPart_001_01C02EE8.1BE97930-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 14:54: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 OAA04947 for ; Thu, 5 Oct 2000 14:54:13 -0400 (EDT) Received: from standards (47.234.32.16:4336) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9DC1A@standards.nortelnetworks.com>; Thu, 5 Oct 2000 14:37:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25945 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 14:37:35 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9DC19@standards.nortelnetworks.com>; Thu, 5 Oct 2000 14:37:35 -0400 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Thu Oct 5 14:50:18 EDT 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Thu Oct 5 14:50:16 EDT 2000 Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP id 544725701F; Thu, 5 Oct 2000 13:50:15 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <5F05C89FB2F8D211B6430008C791912703EA81A6@esealnt190> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20001005185015.544725701F@king.research.bell-labs.com> Date: Thu, 5 Oct 2000 13:50:15 -0500 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: [MOBILE-IP] Differences between the two MIPv4 handoff approaches X-To: "Karim El-Malki (ERA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <5F05C89FB2F8D211B6430008C791912703EA81A6@esealnt190> Content-Transfer-Encoding: 7bit Hi, I wanted to respond to some of the points Karim made, which I hope will help to clarify the differences between the two drafts: "Karim El-Malki (ERA)" (KE) writes: KE> Proactive Handoffs draft = draft-calhoun-mobileip-proactive-fa-02 KE> Fast Handoffs draft = draft-elmalki-mobileip-fast-handoffs-03 KE> 1) The Fast Handoffs draft allows both the network and the KE> MN to control L3 handoffs just as normal Mobile IP (RFC2002). KE> The MN performs Mobile IP Registrations and is therefore in KE> control as to when and with which agent it registers. The KE> network is also in control since it may decide whether to KE> send the MN an agent advertisement to trigger the MN's KE> movement (without which the MN will not perform movement KE> detection and MIP Registration). The network may also KE> advertise but reject the MN's Registration and thus again KE> exercise control. In Proactive handoffs the MN has no control KE> over the handoff and may only react to the network-controlled KE> handoff after it has obtained L2 connectivity to the new FA KE> and starts receiving data from it. Thus the handoff KE> is forced on the MN and the MN may only react if and KE> when the new FA decides to advertise. The terms "control" and "force" should be taken with a grain of salt here. It is true that the MN, in the Proactive draft, does not receive an agent advertisement before the handoff, but this is for a very good reason: we are decoupling the Mobile IP layer-3 handoff from the underlying layer-2 handoff. In typical cellular link layers, there is no time for the Mobile IP protocol (advert/request/response) to run before the actual handoff must be over and done with and connectivity to the old FA is lost. To use Karim's Fast Handoff draft, you need to make sure that the advert/request/response can run after link-layer power measurements indicate a likely handoff, but before connectivity to the current FA is lost. This imposes very tight real-time requirements on the MIP client implementation that we were unwilling to impose in the Proactive draft - my feeling is that this runs counter to the Internet design philosophy. You can think of Proactive handoffs as a way to remove the layer-3 messaging from the critical handoff path; the network proactively sets up a tunnel from the old point of attachment to the new point of attachment, and the MN can register there at its leisure. KE> 2) The Fast Handoffs draft allows the MN to register with KE> the new FA (or GFA) before it moves and before it obtains L2 KE> connectivity to that new FA, thus anticipating the MN's KE> movement. By interacting with L2 it is possible for the KE> FA to synchronize such a registration with the cellular KE> network's mobility such that the new Registration is KE> completed before the MN is instructed to perform a handoff KE> at L2. Local HA functionality (GFA) is used to limit the KE> RTT for the MN's registration. In this way we potentially KE> eliminate the service disruption caused by L3 handoffs and KE> limit the MN's service disruption period to that imposed by KE> the specific L2. Again, this indicates a pretty tight real-time coupling between the MIP client and the L2 that we wanted to avoid. Registering after the L2 handoff removes this dependency. Also it eliminates the configuration headaches that are implicit in the Fast Handoffs scheme: how does the current FA get the advertisement from the next FA, how does it propagate the registration over multiple routing hops, and how does the new FA associate the registration with the soon-to-be-established link-layer connection? KE> 3) The same amount of Registrations/Advertisement are sent/received KE> by an active MN using Proactive or Fast Handoffs for the support KE> of real-time services such as VoIP. The main difference is that KE> in Fast Handoffs the Registration is performed by the MN before KE> it performs a handoff to the new FA, while in Proactive handoffs KE> this is done after the MN has performed a handoff to the new KE> FA and once it is receiving traffic through the new FA. Yup. KE> 4) It is not clear in the proactive approach how an intersystem KE> handoff is handled. For example a handoff occuring between two KE> different wireless technologies. If the proactive approach is KE> to be used for handoffs, and if the MN has a choice of two KE> different systems, it is not possible for the MN to choose which KE> FA it wants to be connected to (until after the MN has been handed KE> off to the new FA). Hence a handoff may result in connecting the KE> MN to a less preferred FA. This is especially true if the FAs KE> choose not to send agent advertisements for very long periods as KE> suggested by the draft. This situation will not arise in Fast KE> Handoffs. Inter-system handoffs using the same technology are exactly where the Proactive approach is intended to be used. The neighboring FAs know about each other and have a security association, in the same way that neighboring Radio Access Networks in today's cellular systems know about each other (otherwise they would not be able to perform a hard handoff). When a handoff from one to another is indicated, a proactive tunnel is set up and the handoff indication is sent to the MN. No involvement from the MN's MIP client is required until after the real-time handoff is complete. For inter-system handoffs using different technologies, I don't see why the network needs to provide any special support over RFC 2002. The MN can presumably use both technologies simultaneously (otherwise the handoff cannot possibly be smooth) and can listen for advertisements on both devices. When the MN chooses, and without any special assistance from the network, it may register on the new technology (let's say, 802.11) and allow its old registration (let's say, on the cdma2000 network) to expire. In the meantime, who cares if the MN was momentarily connected to a new cdma2000 RAN? The temporary proactive handoff provides service to the MN while it is registering on the 802.11 network, and the MN wasn't required to do anything! KE> 5) The proactive draft states that a FA MAY choose to send an KE> Agent Advertisement to the MN after the handoff has taken place. KE> The length of time after which the advertisement is sent is KE> unclear. If simultaneous bindings are used (which is suggested by KE> the draft), this will result in long lifetimes for the KE> simultaneous bindings and consequently an inefficient use of KE> bandwidth since multiple copies of the same packet are transmitted KE> to FAs. In Fast Handoffs simultaneous bindings will have short KE> lifetimes in order to minimize bandwidth consumption. Obviously, the network operator must decide how to set these parameters for optimal network utilization. If registration is not required for some time then use of the 'S' bit may not be appropriate. However, if it is possible for the MN to "ping-pong" between two different FAs very rapidly, then the simultaneous registrations are quite useful - multiple copies of packets are exactly what is desired, on copy transmitted from the old FA (if a link layer connection to the MN exists there) and another copy from the new FA (again, if a link layer connection to the MN exists there). Forcing the MN to send MIP registrations on each ping-pong event is likely to lead to much greater strain on the MIP client implementation. In summary, I think the Fast Handoffs draft has some hidden costs associated with it (tight L2 coupling, configuration of adverts from neighbor FAs, getting "remote" registration to work properly) that may not be immediately obvious on a first read-through. The Proactive draft requires some extra support from the network elements but allows us to use a completely vanilla (non real-time) RFC 2002 MIP client implementation. The frequency of advertisements/registrations can be adjusted for optimum end-to-end performance without regard to the rate of handoffs in the underlying L2 technology. -Pete From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 15:29: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 PAA05629 for ; Thu, 5 Oct 2000 15:29:56 -0400 (EDT) Received: from standards (47.234.32.16:2093) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9DCAD@standards.nortelnetworks.com>; Thu, 5 Oct 2000 15:13:31 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26095 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 15:13:31 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9DC8B@standards.nortelnetworks.com>; Thu, 5 Oct 2000 15:03:30 -0400 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Thu Oct 5 15:17:58 EDT 2000 Received: from blhothuelpc (thuelpc [135.180.240.114]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id PAA06470; Thu, 5 Oct 2000 15:17:55 -0400 (EDT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0059_01C02EDF.3980F030" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <005801c02f00$c0929030$72f0b487@dnrc.belllabs.com> Date: Thu, 5 Oct 2000 15:16:24 -0400 Reply-To: Sandy Thuel Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Sandy Thuel Subject: Re: [MOBILE-IP] Are requirements required? X-To: "Hesham Soliman (EPA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A5089EB301@eaubrnt018.epa.ericsson.se> This is a multi-part message in MIME format. ------=_NextPart_000_0059_01C02EDF.3980F030 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: [MOBILE-IP] Are requirements required?Hi Hesham, Sorry I didn't get to your email sooner. => I was guessing that's what was on your mind, may I ask why fast handoff = micromobility ? If we can achieve the performance targets that we're aiming for using MIP and some extensions wouldn't that be better and much less complex than inventing new protocols ? Let alon saving years of IETF work ? I think we have a terminology problem that is causing all this confusion so let me take a stab at defining these terms based on your comments and please correct me if I have misunderstood you: fast handoff support: approaches to enhance the handover performance of Mobile IP by using existing Mobile IP mechanisms possibly with some extensions. micro-mobility support: approaches to enhance handover performance of Mobile IP by defining new protocols that work in conjunction with Mobile IP while not adhering to conventional Mobile IP mechanisms. Is this a reasonable definition for starters? If so, we can then discuss the relative merits and disadvantages of each. Thanks, Sandy ------=_NextPart_000_0059_01C02EDF.3980F030 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] Are requirements required?
Hi=20 Hesham,
 
Sorry=20 I didn't get to your email sooner.

=3D> I was guessing = that's what was=20 on your mind, may I ask why
fast handoff =3D micromobility ?
If we can achieve the performance targets that = we're aiming=20 for
using MIP = and some=20 extensions wouldn't that be better and much less
complex than inventing new = protocols ? Let=20 alon saving years of IETF work ?  

I=20 think we have a terminology problem that is causing all this confusion = so let=20 me take a stab at defining these terms based on your=20 comments and please correct me if I have misunderstood = you:

fast=20 handoff support: approaches to enhance the handover performance of = Mobile IP=20 by using existing Mobile IP mechanisms possibly with some = extensions. =20

micro-mobility support: = approaches to=20 enhance handover performance of Mobile IP by defining new protocols = that work=20 in conjunction with Mobile IP while not adhering to=20 conventional Mobile IP = mechanisms.

Is this=20 a reasonable definition for starters?  If so, we can then=20 discuss the relative merits and disadvantages of=20 each.

Thanks,

Sandy



------=_NextPart_000_0059_01C02EDF.3980F030-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 16:04: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 QAA06043 for ; Thu, 5 Oct 2000 16:04:06 -0400 (EDT) Received: from standards (47.234.32.16:2093) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9DD7C@standards.nortelnetworks.com>; Thu, 5 Oct 2000 15:47:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26322 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 15:47:41 -0400 Received: from swan.prod.itd.earthlink.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9DD40@standards.nortelnetworks.com>; Thu, 5 Oct 2000 15:37:40 -0400 Received: from mail.earthlink.net (1Cust249.tnt3.panama-city.fl.da.uu.net [63.15.220.249]) by swan.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with SMTP id MAA26132; Thu, 5 Oct 2000 12:45:41 -0700 (PDT) Received: from marketing12@rocketmail.com by marketing12@rocketmail.com (8.8.5/8.6.5) with SMTP id GAA05644 for ; Thu, 05 Oct 2000 13:53:58 -0600 (EST) Message-ID: <> Date: Thu, 5 Oct 2000 13:53:58 EST Reply-To: marketing12@ROCKETMAIL.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: marketing12@ROCKETMAIL.COM Subject: [MOBILE-IP] MAKE MONEY NOW with pc To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM HELLO: THIS IS AN ADVERTISEMENT FOR 50 MILLION E-MAIL ADDRESSES ON CD-ROM. IF YOU HAVE NO INTEREST IN THIS INFORMATION, PLEASE CLICK DELETE. THANK YOU. Dear Consumer, Increase your business sales! How?? By targeting millions of buyers via e-mail !! We are offering over 50 million FRESH, DELIVERABLE, e-mail addresses on CD-ROM. The cd-rom includes targeted addresses, such as business opportuinty seekers, sports buffs, mlm, impulsive buyers and investors. The cd-rom also includes general internet, United States, United kingdom, mixed domains, International, Canadian, earthlink, aol, compuserve, misc and much more. The list's are divided into groups and are compressed. This will allow you to use the names right off the cd. ORDER IN THE NEXT 7 DAYS AND RECEIVE AN ADDITIONAL CD-ROM WITH MILLIONS OF DELIVERABLE E-MAIL ADDRESSES, AND THE BULK MASS MAILER BULKING SOFTWARE FREE!! THE TWO BONUSES ALONE ARE WORTH ACTING NOW! The bonus cd-rom contains such address as general internet, msn, aol, compuserve, delphi and much more! The bonus bulk software is designed to get the mail out fast! THE BONUSES ALONE ARE WORTH HUNDRED'S!! ACT NOW AND RECEIVE ALL THIS FOR AN ALL TIME UNBELIEVEABLE LOW, LOW PRICE OF $39.95 THAT'S RIGHT ONLY $39.95 BUT YOU MUST ORDER NOW! ORDER INFORMATION: SIMPLY SEND $39.95, CHECK, OR MONEY ORDER, US FUNDS, PAYABLE TO: R. GOODWIN CREDIT CARD ORDERS, FILL OUT FORM BELOW. SHIP TO: MARKETING AND MORE PO BOX 1862, SANTA ROSA BEACH, FL 32459 (cut and send form below) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- - - - - - - Print Name: ________________________________________ Address: ________________________________________ City/State/Zip: ______________________________________ CreditCard number: ____________________________________ Exp. Date: ________________________ *Signature required for credit card orders__________________________ ($39.95 e-name cd & 2bonuses) Thank you for your order! If we have reached you in error, and you would like to be removed carla7@dcemail.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 17:08: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 RAA06943 for ; Thu, 5 Oct 2000 17:08:31 -0400 (EDT) Received: from standards (47.234.32.16:2093) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9DEC4@standards.nortelnetworks.com>; Thu, 5 Oct 2000 16:51:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26834 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 16:51:50 -0400 Received: from zrtps06u.us.nortel.com (47.140.48.52:36761) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9DEC3@standards.nortelnetworks.com>; Thu, 5 Oct 2000 16:51:45 -0400 Received: from qhars002.nortel.com (zhars00t.europe.nortel.com [47.101.112.102]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id e95L6Gf16944 for ; Thu, 5 Oct 2000 17:06:16 -0400 (EDT) Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Thu, 5 Oct 2000 22:06:00 +0100 Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Thu, 5 Oct 2000 17:05:36 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 5 Oct 2000 17:05:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02F0F.FD6D0850" X-Orig: Message-ID: Date: Thu, 5 Oct 2000 17:05:28 -0400 Reply-To: Muhammad Jaseemuddin Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Muhammad Jaseemuddin Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt X-To: "Casati, Alessio (Alessio)" 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_01C02F0F.FD6D0850 Content-Type: text/plain; charset="iso-8859-1" Alessio, please see my comments in-line. > -----Original Message----- > From: Casati, Alessio (Alessio) [SMTP:acasati@LUCENT.COM] > Sent: Wednesday, October 04, 2000 3:27 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] FW: I-D > ACTION:draft-jaseem-rap-cops-mip-00.txt > > My question is: if some form of policy management will be performed using > COPS, what makes the PEP/PDP interaction inherently different > when mobile IP is used? > [MJ] COPS defines how PEP and PDP interact, but does not define what they are interacting about. We need a COPS usage that defines the content of these interactions for mobile IP. I think this point was further discussed when we had discussed about handling MIP extensions. > I ask this question without having carefully read the draft, > but, if you have time, this could make your proposal's > scope clearer. > > > thanks > > > alessio > > > ---------- > > From: Abderrahmane Lakas[SMTP:alakas@NORTELNETWORKS.COM] > > Reply To: Abderrahmane Lakas > > Sent: 04 October 2000 19:29 > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: [MOBILE-IP] FW: I-D > > ACTION:draft-jaseem-rap-cops-mip-00.txt > > > > The comments to this draft are understood and well taken. Let me just > > clarify that our intent (authors) is neither to use COPS as a protocol > for > > AAA, nor to open up any AAA-COPS discussion on whatever aspects of > > management. > > > > COPS is used here for non-AAA related aspects of Mobile IP. In our > draft, > > we propose a way to notify the PDP with the presence of MN for which > > policy-related configurations may be applied. COPS looks at the relevant > > extensions in the registration messages in order to make policy-related > > decisions. The AAA extensions are handled by AAA authority. > > > > We understand that we may not have highlighted it enough in the draft, > but > > we are not in any way proposing AAA solution for Mobile IP. > > > > Our assumptions here is that AAA handles AAA things, and COPS handles > > policy-related things. It's not clear yet for us how both coordinate, > but > > we assume that the PDP needs to know an MN has attached to the mobility > > agent, and policies may need to be applied to it. For example, based on > > the received extensions, the PDP may decide to install the MN's QoS > > profile. Other extensions that are or will be defined in the future may > > require some policy-management through COPS. > > > > Finally, this proposal has merit only if COPS is used for policy > > management. > > > > - Abderrahmane > > > > -----Original Message----- > > From: pcalhoun@eng.sun.com [ mailto:Pat.Calhoun@ENG.SUN.COM] > > Sent: Wednesday, October 04, 2000 10:07 AM > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > > > > > Ok, I'll be the first one to reply, and if you don't mind, I'll take off > > the > > white gloves (not that I wear them *that* often). > > > > Why? > > > > The IETF has already decided that network access (and specifically > Mobile > > IP) > > authentication, authorization and accounting is done through the > protocol > > that > > was selected in the AAA WG. COPS was a potential protocol, and did not > > succeed. > > So may I ask why you insist on opening up the can of worms all over > > again? > > Hasn't the past 2 years of AAA run around been enough? > > > > Am I missing something obvious? Or are some COPS people refusing to let > > the > > AAA do its work? Or is causing confusion in the marketplace the ultimate > > goal? > > > > PatC > > > > > We have submitted a draft defining COPS usage for Mobile IP. The > > > announcement is attached below. We will appreciate any comments. > > > > > > - Muhammad Jaseemuddin > > > > > > > -----Original Message----- > > > > From: yaniv@iphighway.com [SMTP:yaniv@iphighway.com] > > > > Sent: Wednesday, October 04, 2000 7:19 AM > > > > To: rap@iphighway.com > > > > Subject: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > > > > > > > To: IETF-Announce: ; > > > > CC: rap@iphighway.com > > > > From: Internet-Drafts@ietf.org > > > > Reply-to: Internet-Drafts@ietf.org > > > > Subject: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > > > Date: Wed, 04 Oct 2000 06:54:46 -0400 > > > > Sender: nsyracus@cnri.reston.va.us > > > > > > > > --NextPart > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > > directories. > > > > > > > > > > > > Title : COPS usage for Mobile IP (MIP) > > > > Author(s) : M. Jaseemuddin, A. Lakas > > > > Filename : draft-jaseem-rap-cops-mip-00.txt > > > > Pages : 14 > > > > Date : 03-Oct-00 > > > > > > > > Mobile IP is a protocol that is used to achieve transparent routing > > > > of IP packets to a mobile node. A mobile node obtains a care-of- > > > > address in the foreign network and registers that address with the > > > > home agent. The home agent as well as the foreign agent can apply > > > > policies to the mobile node registration. This draft defines COPS > > > > [1] usage for Mobile IPv4 [2]. It describes how COPS is used to > > > > control Mobile IP registration based on policies. It defines the > > > > interactions between the PEP and the PDP to handle Mobile IP > > > > registration messages. It also provides a guideline for mobility > > > > agents on how to use this COPS client with regards to the > > > > registration messages. > > > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-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: <20001003122806.I-D@ietf.org> > > > > > > > > ENCODING mime > > > > FILE /internet-drafts/draft-jaseem-rap-cops-mip-00.txt > > > > > > > > --OtherAccess > > > > Content-Type: Message/External-body; > > > > name="draft-jaseem-rap-cops-mip-00.txt"; > > > > site="ftp.ietf.org"; > > > > access-type="anon-ftp"; > > > > directory="internet-drafts" > > > > > > > > > > > > --OtherAccess-- > > > > > > > > --NextPart-- > > > > ------_=_NextPart_001_01C02F0F.FD6D0850 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] FW: I-D = ACTION:draft-jaseem-rap-cops-mip-00.txt

Alessio,

 please see my = comments in-line.

------_=_NextPart_001_01C02F0F.FD6D0850-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 17: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 RAA07172 for ; Thu, 5 Oct 2000 17:24:16 -0400 (EDT) Received: from standards (47.234.32.16:2093) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9DF26@standards.nortelnetworks.com>; Thu, 5 Oct 2000 17:07:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26964 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 17:07:49 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:50800) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9DF25@standards.nortelnetworks.com>; Thu, 5 Oct 2000 17:07:47 -0400 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 HAA28892; Fri, 6 Oct 2000 07:19:36 +1000 (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 IAA17122; Fri, 6 Oct 2000 08:21:48 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Fri, 6 Oct 2000 08:21:57 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02F12.493B6540" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB32D@eaubrnt018.epa.ericsson.se> Date: Fri, 6 Oct 2000 08:21:55 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac hes X-To: Pete McCann 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_01C02F12.493B6540 Content-Type: text/plain; charset="iso-8859-1" Pete, Some initial comments below, Karim will probably add to my comments. > "Karim El-Malki (ERA)" (KE) writes: > > KE> Proactive Handoffs draft = draft-calhoun-mobileip-proactive-fa-02 > KE> Fast Handoffs draft = draft-elmalki-mobileip-fast-handoffs-03 > > KE> 1) The Fast Handoffs draft allows both the network and the > KE> MN to control L3 handoffs just as normal Mobile IP (RFC2002). > KE> The MN performs Mobile IP Registrations and is therefore in > KE> control as to when and with which agent it registers. The > KE> network is also in control since it may decide whether to > KE> send the MN an agent advertisement to trigger the MN's > KE> movement (without which the MN will not perform movement > KE> detection and MIP Registration). The network may also > KE> advertise but reject the MN's Registration and thus again > KE> exercise control. In Proactive handoffs the MN has no control > KE> over the handoff and may only react to the network-controlled > KE> handoff after it has obtained L2 connectivity to the new FA > KE> and starts receiving data from it. Thus the handoff > KE> is forced on the MN and the MN may only react if and > KE> when the new FA decides to advertise. > > The terms "control" and "force" should be taken with a grain of salt > here. It is true that the MN, in the Proactive draft, does not > receive an agent advertisement before the handoff, but this is for a > very good reason: we are decoupling the Mobile IP layer-3 handoff from > the underlying layer-2 handoff. In typical cellular link layers, > there is no time for the Mobile IP protocol (advert/request/response) > to run before the actual handoff must be over and done with and > connectivity to the old FA is lost. > How did you make that conclusion ? Of course there is time. There is lots of messaging that goes on in a "typical" cellular handoff. Can you be more specific ? > To use Karim's Fast Handoff draft, you need to make sure that the > advert/request/response can run after link-layer power measurements > indicate a likely handoff, but before connectivity to the current > FA is lost. This imposes very tight real-time requirements on the > MIP client implementation that we were unwilling to impose in the > Proactive draft - my feeling is that this runs counter to the Internet > design philosophy. > Which design philosophy is that ? RFC 2002 ? because that's what the draft tries to maintain. Again can you please be specific ? > You can think of Proactive handoffs as a way to > remove the layer-3 messaging from the critical handoff path; the > network proactively sets up a tunnel from the old point of attachment > to the new point of attachment, and the MN can register there at its > leisure. > Actually I think it attempts to remove L3 signalling from the MN for an unspecified period of time. > KE> 2) The Fast Handoffs draft allows the MN to register with > KE> the new FA (or GFA) before it moves and before it obtains L2 > KE> connectivity to that new FA, thus anticipating the MN's > KE> movement. By interacting with L2 it is possible for the > KE> FA to synchronize such a registration with the cellular > KE> network's mobility such that the new Registration is > KE> completed before the MN is instructed to perform a handoff > KE> at L2. Local HA functionality (GFA) is used to limit the > KE> RTT for the MN's registration. In this way we potentially > KE> eliminate the service disruption caused by L3 handoffs and > KE> limit the MN's service disruption period to that imposed by > KE> the specific L2. > > Again, this indicates a pretty tight real-time coupling between the > MIP client and the L2 that we wanted to avoid. > In the MIP client ? where does the draft say or imply that ? > Registering after > the L2 handoff removes this dependency. Also it eliminates the > configuration headaches that are implicit in the Fast Handoffs > scheme: how does the current FA get the advertisement from the > next FA, how does it propagate the registration over multiple > routing hops, and how does the new FA associate the registration > with the soon-to-be-established link-layer connection? > I'm surprised you're bringing this up again. Please refer to our previous discussion in the archive and the draft. While we're repeating questions : How does a proactive FA get the "next" FA's IP address ? > KE> 4) It is not clear in the proactive approach how an intersystem > KE> handoff is handled. For example a handoff occuring between two > KE> different wireless technologies. If the proactive approach is > KE> to be used for handoffs, and if the MN has a choice of two > KE> different systems, it is not possible for the MN to choose which > KE> FA it wants to be connected to (until after the MN has been handed > KE> off to the new FA). Hence a handoff may result in connecting the > KE> MN to a less preferred FA. This is especially true if the FAs > KE> choose not to send agent advertisements for very long periods as > KE> suggested by the draft. This situation will not arise in Fast > KE> Handoffs. > > Inter-system handoffs using the same technology are exactly where > the Proactive approach is intended to be used. The neighboring FAs > know about each other and have a security association, in the same > way that neighboring Radio Access Networks in today's cellular systems > know about each other (otherwise they would not be able to perform > a hard handoff). When a handoff from one to another is indicated, > a proactive tunnel is set up and the handoff indication is sent to > the MN. No involvement from the MN's MIP client is required until > after the real-time handoff is complete. > > For inter-system handoffs using different technologies, I don't see > why the network needs to provide any special support over RFC 2002. > The MN can presumably use both technologies simultaneously (otherwise > the handoff cannot possibly be smooth) and can listen for > advertisements on both devices. > What if the FA's are proactive and are configured not to advertise for very long periods ? Your proposal takes us away from RFC 2002 and that's the price you pay. > When the MN chooses, and without any > special assistance from the network, it may register on the new > technology (let's say, 802.11) and allow its old registration (let's > say, on the cdma2000 network) to expire. In the meantime, who cares > if the MN was momentarily connected to a new cdma2000 RAN? The > temporary proactive handoff provides service to the MN while it is > registering on the 802.11 network, and the MN wasn't required to do > anything! > Again please refer to my comment above. > KE> 5) The proactive draft states that a FA MAY choose to send an > KE> Agent Advertisement to the MN after the handoff has taken place. > KE> The length of time after which the advertisement is sent is > KE> unclear. If simultaneous bindings are used (which is suggested by > KE> the draft), this will result in long lifetimes for the > KE> simultaneous bindings and consequently an inefficient use of > KE> bandwidth since multiple copies of the same packet are transmitted > KE> to FAs. In Fast Handoffs simultaneous bindings will have short > KE> lifetimes in order to minimize bandwidth consumption. > > Obviously, the network operator must decide how to set these parameters > for optimal network utilization. If registration is not required for > some time then use of the 'S' bit may not be appropriate. > The use of S bit was introduced in Fast Handoffs to reduce the service interruption. I don't understand the point of associating its use with the registration lifetime. It's needed because it's important, not because it's convenient when the registraion lifetime is short. > However, if it is possible for the MN to "ping-pong" between two > different FAs very rapidly, then the simultaneous registrations are > quite useful - multiple copies of packets are exactly what is desired, > on copy transmitted from the old FA (if a link layer connection to the > MN exists there) and another copy from the new FA (again, if a link > layer connection to the MN exists there). Forcing the MN to send MIP > registrations on each ping-pong event is likely to lead to much > greater strain on the MIP client implementation. > Ok so are you saying that FA's can predict whether ping pong will happen or not before the handoff and then decide whether S bit should be used or not ? It does't sound reasonable to me, hence the point made above. Either you use it or not, if you do, then the point above is relevant and if you don't then you have to remove the claims of fixing the ping pong problem in the proactive draft. > In summary, I think the Fast Handoffs draft has some hidden costs > associated with it (tight L2 coupling, configuration of adverts from > neighbor FAs, getting "remote" registration to work properly) that may > not be immediately obvious on a first read-through. > Could you please be specific ? What are the coupling costs compared to proactive ? > The Proactive > draft requires some extra support from the network elements but allows > us to use a completely vanilla (non real-time) RFC 2002 MIP client > implementation. > What is a non-real time client ? > The frequency of advertisements/registrations can be > adjusted for optimum end-to-end performance without regard to the rate > of handoffs in the underlying L2 technology. > Yes I realise that, and as I said earlier some of the points Karim sent shows the consequence of loosening the requirements on FA's to advertise. I'm not saying they have to avertise regularly but we believe they MUST advertise during a handoff. ------_=_NextPart_001_01C02F12.493B6540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] Differences between the two MIPv4 handoff = approaches

Pete,

Some initial = comments below, Karim will probably add to my comments.

    "Karim El-Malki (ERA)" = <Karim.El-Malki@ERA.ERICSSON.SE> (KE) writes:

    KE> Proactive Handoffs draft =3D = draft-calhoun-mobileip-proactive-fa-02
    KE> Fast Handoffs draft =3D = draft-elmalki-mobileip-fast-handoffs-03

    KE> 1) The Fast Handoffs draft = allows both the network and the
    KE> MN to control L3 handoffs just = as normal Mobile IP (RFC2002).
    KE> The MN performs Mobile IP = Registrations and is therefore in
    KE> control as to when and with = which agent it registers. The
    KE> network is also in control = since it may decide whether to
    KE> send the MN an agent = advertisement to trigger the MN's
    KE> movement (without which the MN = will not perform movement
    KE> detection and MIP = Registration). The network may also
    KE> advertise but reject the MN's = Registration and thus again
    KE> exercise control. In Proactive = handoffs the MN has no control
    KE> over the handoff and may only = react to the network-controlled
    KE> handoff after it has obtained = L2 connectivity to the new FA
    KE> and starts receiving data from = it. Thus the handoff
    KE> is forced on the MN and the MN = may only react if and
    KE> when the new FA decides to = advertise.

    The terms "control" and = "force" should be taken with a grain of salt
    here.  It is true that the MN, = in the Proactive draft, does not
    receive an agent advertisement before = the handoff, but this is for a
    very good reason: we are decoupling = the Mobile IP layer-3 handoff from
    the underlying layer-2 handoff.  = In typical cellular link layers,
    there is no time for the Mobile IP = protocol (advert/request/response)
    to run before the actual handoff must = be over and done with and
    connectivity to the old FA is = lost.

    How did you make = that conclusion ? Of course there is time.
    There is lots of = messaging that goes on in a "typical" cellular
    handoff. Can you be = more specific ?

    To use Karim's Fast Handoff draft, you = need to make sure that the
    advert/request/response can run after = link-layer power measurements
    indicate a likely handoff, but before = connectivity to the current
    FA is lost.  This imposes very = tight real-time requirements on the
    MIP client implementation that we = were unwilling to impose in the
    Proactive draft - my feeling is that = this runs counter to the Internet
    design philosophy.=20

    Which design = philosophy is that ? RFC 2002 ? because that's what
    the draft tries to = maintain. Again can you please be specific ?

     You can think of Proactive = handoffs as a way to
    remove the layer-3 messaging from the = critical handoff path; the
    network proactively sets up a tunnel = from the old point of attachment
    to the new point of attachment, and = the MN can register there at its
    leisure.

    Actually I think it = attempts to remove L3 signalling from the MN for
    an unspecified = period of time.=20

    KE> 2) The Fast Handoffs draft = allows the MN to register with
    KE> the new FA (or GFA) before it = moves and before it obtains L2
    KE> connectivity to that new FA, = thus anticipating the MN's
    KE> movement. By interacting with = L2 it is possible for the
    KE> FA to synchronize such a = registration with the cellular
    KE> network's mobility such that = the new Registration is
    KE> completed before the MN is = instructed to perform a handoff
    KE> at L2. Local HA functionality = (GFA) is used to limit the
    KE> RTT for the MN's registration. = In this way we potentially
    KE> eliminate the service = disruption caused by L3 handoffs and
    KE> limit the MN's service = disruption period to that imposed by
    KE> the specific L2.

    Again, this indicates a pretty tight = real-time coupling between the
    MIP client and the L2 that we wanted = to avoid.=20

    In the MIP client ? = where does the draft say or imply that ?

     Registering after
    the L2 handoff removes this = dependency.  Also it eliminates the
    configuration headaches that are = implicit in the Fast Handoffs
    scheme: how does the current FA get = the advertisement from the
    next FA, how does it propagate the = registration over multiple
    routing hops, and how does the new FA = associate the registration
    with the soon-to-be-established = link-layer connection?

    I'm surprised you're = bringing this up again. Please refer to our
    previous discussion = in the archive and the draft.

    While we're = repeating questions :
    How does a = proactive FA get the "next" FA's IP address ?


    KE> 4) It is not clear in the = proactive approach how an intersystem
    KE> handoff is handled. For = example a handoff occuring between two
    KE> different wireless technologies= . If the proactive approach is
    KE> to be used for handoffs, and = if the MN has a choice of two
    KE> different systems, it is not = possible for the MN to choose which
    KE> FA it wants to be connected to = (until after the MN has been handed
    KE> off to the new FA). Hence a = handoff may result in connecting the
    KE> MN to a less preferred FA. = This is especially true if the FAs
    KE> choose not to send agent = advertisements for very long periods as
    KE> suggested by the draft. This = situation will not arise in Fast
    KE> Handoffs.

    Inter-system handoffs using the same = technology are exactly where
    the Proactive approach is intended to = be used.  The neighboring FAs
    know about each other and have a = security association, in the same
    way that neighboring Radio Access = Networks in today's cellular systems
    know about each other (otherwise they = would not be able to perform
    a hard handoff).  When a handoff = from one to another is indicated,
    a proactive tunnel is set up and the = handoff indication is sent to
    the MN.  No involvement from the = MN's MIP client is required until
    after the real-time handoff is = complete.

    For inter-system handoffs using = different technologies, I don't see
    why the network needs to provide any = special support over RFC 2002.
    The MN can presumably use both = technologies simultaneously (otherwise
    the handoff cannot possibly be = smooth) and can listen for
    advertisements on both = devices.=20

    What if the FA's are = proactive and are configured not to advertise for very
    long periods ? Your = proposal takes us away from RFC 2002 and that's
    the price you pay. =

     When the MN chooses, and without = any
    special assistance from the network, = it may register on the new
    technology (let's say, 802.11) and = allow its old registration (let's
    say, on the cdma2000 network) to = expire.  In the meantime, who cares
    if the MN was momentarily connected = to a new cdma2000 RAN?  The
    temporary proactive handoff provides = service to the MN while it is
    registering on the 802.11 network, = and the MN wasn't required to do
    anything!

    Again please refer = to my comment above.=20

    KE> 5) The proactive draft states = that a FA MAY choose to send an
    KE> Agent Advertisement to the MN = after the handoff has taken place.
    KE> The length of time after which = the advertisement is sent is
    KE> unclear. If simultaneous = bindings are used (which is suggested by
    KE> the draft), this will result = in long lifetimes for the
    KE> simultaneous bindings and = consequently an inefficient use of
    KE> bandwidth since multiple = copies of the same packet are transmitted
    KE> to FAs. In Fast Handoffs = simultaneous bindings will have short
    KE> lifetimes in order to minimize = bandwidth consumption.

    Obviously, the network operator must = decide how to set these parameters
    for optimal network = utilization.  If registration is not required for
    some time then use of the 'S' bit may = not be appropriate.

    The use of S bit was = introduced in Fast Handoffs to reduce the
    service = interruption. I don't understand the point of associating its
    use with the = registration lifetime. It's needed because it's important,
    not because it's = convenient when the registraion lifetime is short.

    However, if it is possible for the MN = to "ping-pong" between two
    different FAs very rapidly, then the = simultaneous registrations are
    quite useful - multiple copies of = packets are exactly what is desired,
    on copy transmitted from the old FA = (if a link layer connection to the
    MN exists there) and another copy = from the new FA (again, if a link
    layer connection to the MN exists = there).  Forcing the MN to send MIP
    registrations on each ping-pong event = is likely to lead to much
    greater strain on the MIP client = implementation.

    Ok so are you saying = that FA's can predict whether ping pong will happen
    or not before the = handoff and then decide whether S bit should be used or not ?
    It does't sound = reasonable to me, hence the point made above.
    Either you use it = or not, if you do, then the point above is relevant and if you
    don't then you have = to remove the claims of fixing the ping pong problem in
    the proactive = draft.

    In summary, I think the Fast Handoffs = draft has some hidden costs
    associated with it (tight L2 = coupling, configuration of adverts from
    neighbor FAs, getting = "remote" registration to work properly) that may
    not be immediately obvious on a first = read-through. =20

    Could you please be = specific ? What are the coupling costs compared to
    proactive ?

    The Proactive
    draft requires some extra support = from the network elements but allows
    us to use a completely vanilla (non = real-time) RFC 2002 MIP client
    implementation. =20

    What is a non-real = time client ?

    The frequency of = advertisements/registrations can be
    adjusted for optimum end-to-end perfor= mance without regard to the rate
    of handoffs in the underlying L2 = technology.

    Yes I realise that, = and as I said earlier some of the points Karim sent shows
    the consequence of = loosening the requirements on FA's to advertise. I'm not saying
    they have to = avertise regularly but we believe they MUST advertise during a = handoff.

------_=_NextPart_001_01C02F12.493B6540-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 17:32: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 RAA07309 for ; Thu, 5 Oct 2000 17:32:07 -0400 (EDT) Received: from standards (47.234.32.16:2093) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9DF6D@standards.nortelnetworks.com>; Thu, 5 Oct 2000 17:13:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27062 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 17:13:15 -0400 Received: from zrtps06u.us.nortel.com (47.140.48.52:37032) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9DF6C@standards.nortelnetworks.com>; Thu, 5 Oct 2000 17:13:15 -0400 Received: from qhars002.nortel.com (zhars00t.europe.nortel.com [47.101.112.102]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id e95LRff17706 for ; Thu, 5 Oct 2000 17:27:42 -0400 (EDT) Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Thu, 5 Oct 2000 22:27:00 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Thu, 5 Oct 2000 16:03:55 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 5 Oct 2000 16:03:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02F0F.BD7DB140" Message-ID: Date: Thu, 5 Oct 2000 16:03:41 -0500 Reply-To: Muhammad Jaseemuddin Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Muhammad Jaseemuddin Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt X-To: "Casati, Alessio (Alessio)" 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_01C02F0F.BD7DB140 Content-Type: text/plain > -----Original Message----- > From: Casati, Alessio (Alessio) [SMTP:acasati@LUCENT.COM] > Sent: Wednesday, October 04, 2000 2:39 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] FW: I-D > ACTION:draft-jaseem-rap-cops-mip-00.txt > > > I know this is going to get dinged by many of the people I work with > > (on > > this list, and in the office), but is there some reason the authors > can't > > have > > an individual submission for an informational RFC? RFC2356 comes to > mind > > (use > > of SKIP FW traversal in Mobile IP), published by the mobile ip working > > group > > in June 1998, after the decision of the IPSec WG (and Jeff Schiller) for > > ISAKMP/Oakley as the IPSec protocol of choice. If the authors want to > > work on > > this, it doesn't have to be an official working group document (hence > the > > name > > d-jaseem-..., not d-i-mip-...) to get some review from mobile ip WG > > members > > willing to read it (if any, and presuming it works). If the authors > want > > to > > move it to anything more than informational, however, it seems likely to > > be > > blocked by the IESG... > > > > > Your line of reasoning is somewhat valid in general terms to me. > > However, this intention should have been clear either from the > posting from the authors or from the abstract. > > Neither guides us in that direction. Nor mention of the > currently selected approach is anywhere in the document. > [MJ] That depends on the need and the interest of the community. Discussions in the RAP and Mobile-IP WGs will determine what directions to take. > Of course, if they authors to go for an individual info RFC, they can try, > but I would claim that since COPS is standards track too, > things may not be as similar to SKIP firewall traversal as it may look > like > :). > > > Let's wait and see what the authors want to tell us (if they are on this > ML) > > alessio ------_=_NextPart_001_01C02F0F.BD7DB140 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] FW: I-D = ACTION:draft-jaseem-rap-cops-mip-00.txt

    -----Original Message-----
    From:   Casati, Alessio (Alessio) = [SMTP:acasati@LUCENT.COM]
    Sent:   Wednesday, October 04, 2000 2:39 PM
    To:     MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: [MOBILE-IP] FW: I-D = ACTION:draft-jaseem-rap-cops-mip-00.txt

    >     I know = this is going to get dinged by many of the people I work with
    > (on
    > this list, and in the office), = but is there some reason the authors can't
    > have
    > an individual submission for an = informational RFC?  RFC2356 comes to mind
    > (use
    > of SKIP FW traversal in Mobile = IP), published by the mobile ip working
    > group
    > in June 1998, after the decision = of the IPSec WG (and Jeff Schiller) for
    > ISAKMP/Oakley as the IPSec = protocol of choice.  If the authors want to
    > work on
    > this, it doesn't have to be an = official working group document (hence the
    > name
    > d-jaseem-..., not d-i-mip-...) = to get some review from mobile ip WG
    > members
    > willing to read it (if any, and = presuming it works).  If the authors want
    > to
    > move it to anything more than = informational, however, it seems likely to
    > be
    > blocked by the IESG...
    >
    >
    Your line of reasoning is somewhat = valid in general terms to me.

    However, this intention should have = been clear either from the
    posting from the authors or from the = abstract.

    Neither guides us in that direction. = Nor mention of the
    currently selected approach is = anywhere in the document.

    [MJ]  That depends on the need and the interest of = the community. Discussions in the RAP and Mobile-IP WGs will determine = what directions to take.

    Of course, if they authors to go for = an individual info RFC, they can try,
    but I would claim that since COPS is = standards track too,
    things may not be as similar to SKIP = firewall traversal as it may look like
    :).


    Let's wait and see what the authors = want to tell us (if they are on this ML)

    alessio

------_=_NextPart_001_01C02F0F.BD7DB140-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 17:46: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 RAA07441 for ; Thu, 5 Oct 2000 17:46:00 -0400 (EDT) Received: from standards (47.234.32.16:2093) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9DFE2@standards.nortelnetworks.com>; Thu, 5 Oct 2000 17:29:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27224 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 17:29:40 -0400 Received: from zrtps06u.us.nortel.com (47.140.48.52:37300) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9DFE1@standards.nortelnetworks.com>; Thu, 5 Oct 2000 17:29:40 -0400 Received: from qhars002.nortel.com (zhars00t.europe.nortel.com [47.101.112.102]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id e95LiBf18446 for ; Thu, 5 Oct 2000 17:44:11 -0400 (EDT) Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com; Thu, 5 Oct 2000 22:43:54 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Thu, 5 Oct 2000 16:06:50 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 5 Oct 2000 16:10:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02F10.B8128EA0" X-Orig: Message-ID: Date: Thu, 5 Oct 2000 16:10:42 -0500 Reply-To: Muhammad Jaseemuddin Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Muhammad Jaseemuddin Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt X-To: "Casati, Alessio (Alessio)" X-cc: Abderrahmane Lakas 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_01C02F10.B8128EA0 Content-Type: text/plain > -----Original Message----- > From: Casati, Alessio (Alessio) [SMTP:acasati@lucent.com] > Sent: Thursday, October 05, 2000 11:35 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Jaseemuddin, Muhammad > [WDLN2:AN33:EXCH] > Cc: Lakas, Abderrahmane [WDLN2:AN33:EXCH] > Subject: RE: [MOBILE-IP] FW: I-D > ACTION:draft-jaseem-rap-cops-mip-00.txt > > > > > > It seems to me that in case some policies are related > > to QoS, then a QoS client is better suited than a MIP client. > > maybe we could define MIP QoS extensions that could be used by > > (that is are compatible with) the COPS RSVP client (just as a dumb > > example). > > > > [MJ] You are very close to what has motivated us > > > Cool! > > > . Yes, we can define some MIP extension for QoS, but where that > extension > > will be processed? Most likely at PDP. For that, we need to communicate > > that QoS extension to the PDP. We can do that using COPS-MIP. > > > Or COPS RSVP if we are smart enough to reuse work done by others... > [MJ] You can not do it with the current definition of COPS-RSVP, unless you extend it to handle MIP messages. But then, most likely you'll end up with some thing like COPS-MIP and thats what we propose. > > I am glad that you mentioned COPS-RSVP. Because, that helps > > understand COPS-MIP as it is analogous to COPS-RSVP. They both use the > > same COPS signaled policy model. However COPS-RSVP is designed to > > understand and handle RSVP objects. In order to handle MIP extensions, > we > > need a new COPS client that understands and handle MIP extensions. > That's > > what we think COPS-MIP is for. > > > I would regard COPS MIP as useful as COPS IP. The fact a user is moving > should not > affect policy mechanisms. > > [MJ] I am not sure if I understand what you mean my COPS IP. Anyway I suggest that we take COPS related discussion to RAP WG where this draft was submitted. Comments on this draft for MIP related issues are welcome here. > > If instead you are talking about roaming policies, then probably > > they > > could naturally fit within the AAA framework. > > Any user profile can also be > > downloaded to a PEP (which does not necessarily speak COPS) when > > the user registers and as such the home AAA server is queried. > > This is somehow consistent with the HSS model... > > The envelope of such profiles may > > not be COPS. It may be part of the AAA protocol (more usefully, I think) > > > > > [MJ] Yes the roaming policies are most likely handled by AAA > > server, and if the PDP needs information about them, then the PDP can > > communicate with the AAA server. But, whichever mechanisms are used to > > handle roaming policies, should not affect COPS-MIP. > > > If COPS MIP won't exist, as I personally think, this is going to be most > likely. > > > For other "service specific" policy, again, the MIP extensions > > possibly should be defined so that they could be used by the > > client for that specific service. > > > > [MJ] Which client? If you are talking about COPS client, then that > > is COPS-MIP. > > > > > Oh well, > > If I talk about host routing, somebody thinks I talking about CIP > If I talk about a COPS client, somebody thinks it is the COPS MIP > client... > > Please, try not to limit your perspective to the work you have done > (which is pointing out some aspects people could work on, but probably > it is not the best possible solution). > > having said that, I'm still waiting some answers from the backlog > > (there's one on authentication handling I'm particularly keen on) > > > Alessio > ------_=_NextPart_001_01C02F10.B8128EA0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] FW: I-D = ACTION:draft-jaseem-rap-cops-mip-00.txt

    -----Original Message-----
    From:   Casati, Alessio (Alessio) = [SMTP:acasati@lucent.com]
    Sent:   Thursday, October 05, 2000 11:35 AM
    To:     MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Jaseemuddin, = Muhammad [WDLN2:AN33:EXCH]
    Cc:     Lakas, Abderrahmane [WDLN2:AN33:EXCH]
    Subject:       = RE: [MOBILE-IP] FW: I-D = ACTION:draft-jaseem-rap-cops-mip-00.txt




    >       It = seems to me that in case some policies are related
    > to QoS, then a QoS client is = better suited than a MIP client.
    > maybe we could define MIP QoS = extensions that could be used by
    > (that is are compatible with) = the COPS RSVP client (just as a dumb
    > example).
    >
    >       = [MJ]  You are very close to what has motivated us
    >
    Cool!

    > . Yes, we can define some MIP = extension for QoS, but where that extension
    > will be processed? Most likely = at PDP. For that, we need to communicate
    > that QoS extension to the PDP. = We can do that using COPS-MIP. 
    >
    Or COPS RSVP if we are smart enough = to reuse work done by others...

    [MJ]  You can not do it with the current definition of = COPS-RSVP, unless you extend it to handle MIP messages. But then, most = likely you'll end up with some thing like COPS-MIP and thats what we = propose.

    >       I = am glad that you mentioned COPS-RSVP. Because, that helps
    > understand COPS-MIP as it is = analogous to COPS-RSVP. They both use the
    > same COPS signaled policy model. = However COPS-RSVP is designed to
    > understand and handle RSVP = objects. In order to handle MIP extensions,  we
    > need a new COPS client that = understands and handle MIP extensions. That's
    > what we think COPS-MIP is = for.
    >
    I would regard COPS MIP as useful as = COPS IP. The fact a user is moving
    should not
    affect policy mechanisms.


    [MJ]  I am not sure if I understand what you mean my = COPS IP. Anyway I suggest that we take COPS related discussion to RAP = WG where this draft was submitted. Comments on this draft for MIP = related issues are welcome here.

    >       If = instead you are talking about roaming policies, then probably
    > they
    > could naturally fit within the = AAA framework.
    > Any user profile can also be =
    > downloaded to a PEP (which does = not necessarily speak COPS) when
    > the user registers and as such = the home AAA server is queried.
    > This is somehow consistent with = the HSS model...
    > The envelope of such profiles = may
    > not be COPS. It may be part of = the AAA protocol (more usefully, I think)
    >
    >       = [MJ]  Yes the roaming policies are most likely handled by = AAA
    > server, and if the PDP needs = information about them, then the PDP can
    > communicate with the AAA server. = But, whichever mechanisms are used to
    > handle roaming policies, should = not affect COPS-MIP.
    >
    If COPS MIP won't exist, as I = personally think, this is going to be most
    likely.

    >       = For other "service specific" policy, again, the MIP = extensions
    > possibly should be defined so = that they could be used by the
    > client for that specific = service.
    >
    >       = [MJ]  Which client? If you are talking about COPS client, then = that
    > is COPS-MIP.
    >
    >
    Oh well,

    If I talk about host routing, somebody = thinks I talking about CIP
    If I talk about a COPS client, = somebody thinks it is the COPS MIP client...

    Please, try not to limit your = perspective to the work you have done
    (which is pointing out some aspects = people could work on, but probably
    it is not the best possible = solution).

    having said that, I'm still waiting = some answers from the backlog

    (there's one on authentication = handling I'm particularly keen on)


    Alessio

------_=_NextPart_001_01C02F10.B8128EA0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 19:06: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 TAA08599 for ; Thu, 5 Oct 2000 19:06:44 -0400 (EDT) Received: from standards (47.234.32.16:2093) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E0D5@standards.nortelnetworks.com>; Thu, 5 Oct 2000 18:50:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27534 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 18:50:24 -0400 Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E0D4@standards.nortelnetworks.com>; Thu, 5 Oct 2000 18:50:24 -0400 Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id TAA25367 for ; Thu, 5 Oct 2000 19:04:55 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id TAA25358 for ; Thu, 5 Oct 2000 19:04:55 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 6 Oct 2000 00:04:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C0487732D@en0060exch001u.uk.lucent.com> Date: Fri, 6 Oct 2000 00:04:41 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt X-To: Muhammad Jaseemuddin To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > [MJ] COPS defines how PEP and PDP interact, but does not define > what they are interacting about. We need a COPS usage that defines the > content of these interactions for mobile IP. > > My question is why do you really need to define a new COPS client for MIP extensions that do not exist which could anyway be defined to be compatible with existing COPS clients. It all boils down to having a reason why one should have a different COPS client for a dial-up user or a mobile IP user to handle QoS policies when the user is roaming. If you provide such reason, then I believe we will have understood the reason why you are proposing this new COPS client. alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 19:18: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 TAA08739 for ; Thu, 5 Oct 2000 19:17:59 -0400 (EDT) Received: from standards (47.234.32.16:2093) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E193@standards.nortelnetworks.com>; Thu, 5 Oct 2000 19:01:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27777 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 19:01:26 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E192@standards.nortelnetworks.com>; Thu, 5 Oct 2000 19:01:25 -0400 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA29135; Thu, 5 Oct 2000 17:15:55 -0600 (MDT) 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 QAA11225; Thu, 5 Oct 2000 16:15:54 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA27872; Thu, 5 Oct 2000 16:15:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Thu, 5 Oct 2000 16:13:45 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt X-To: "Casati, Alessio (Alessio)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <976F7C55E3B2D111A0720008C728549C0487732D@en0060exch001u.uk.lucent.com> Let me perhaps rephrase Alessio's question. Assuming, as you stated, that you aren't trying to do what AAA is doing (that is authentication, authorization and accounting), why is a Mobile IP client different from a PPP or ethernet client? If the mobile node wants to send an RSVP request to the network to allocate resources (or if a provisioning model is used), why is another COPS extension required? I think that Alessio sent a question that remained unanswered. This question had to do with authentication of the mobile node (Specifically the authentication extension). This is starting to smell alot like AAA to me. Looking forward to your response, PatC > > [MJ] COPS defines how PEP and PDP interact, but does not define > > what they are interacting about. We need a COPS usage that defines the > > content of these interactions for mobile IP. > > > > > My question is why do you really need to > define a new COPS client for MIP extensions that do not exist > which could anyway be defined to be compatible with existing > COPS clients. It all boils down to having a reason why > one should have a different COPS client for a dial-up user or > a mobile IP user to handle QoS policies when the user is roaming. > > If you provide such reason, then I believe we will have > understood the reason why you are proposing this new COPS client. > > > > alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 19:29: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 TAA08821 for ; Thu, 5 Oct 2000 19:29:48 -0400 (EDT) Received: from standards (47.234.32.16:2093) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E1FD@standards.nortelnetworks.com>; Thu, 5 Oct 2000 19:13:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27917 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 19:13:33 -0400 Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E1FC@standards.nortelnetworks.com>; Thu, 5 Oct 2000 19:13:33 -0400 Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id TAA01410 for ; Thu, 5 Oct 2000 19:28:04 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id TAA01406 for ; Thu, 5 Oct 2000 19:28:04 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 6 Oct 2000 00:28:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C0487732E@en0060exch001u.uk.lucent.com> Date: Fri, 6 Oct 2000 00:28:02 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt X-To: Muhammad Jaseemuddin To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > . Yes, we can define some MIP extension for QoS, but where that > extension > > will be processed? Most likely at PDP. For that, we need to communicate > > that QoS extension to the PDP. We can do that using COPS-MIP. > > > Or COPS RSVP if we are smart enough to reuse work done by others... > > [MJ] You can not do it with the current definition of COPS-RSVP, > unless you extend it to handle MIP messages. But then, most likely you'll > end up with some thing like COPS-MIP and thats what we propose. > I happen to work on a box called GGSN. We have a RADIUS client that uses protocol configuration options carried in a protocol called GTP. These are collected from a PPP authentication phase that runs between a mobile terminal and a Terminal equipment (basically a phone and a laptop, to exemplify) and transported across a wireless access network, using the radio interface layer 3, and an UMTS backbone, using GTP, to the GGSN. Despite the fact this specific radius client interacts with a protocol that is not PPP, so far we have not come to the IETF to ask the addition of a RADISU GTP client. This tale is to say that independent of the name of the envelope it is possible to reuse existing specs. > I would regard COPS MIP as useful as COPS IP. The fact a user is moving > should not > affect policy mechanisms. > > > [MJ] I am not sure if I understand what you mean my COPS IP. > BY COPS IP I mean a thing with not much use. It does not exist. You are then more or less in a situation close to mine, since, so far, I have not enough elements to understand what COPS MIP is. An applicability example would help (not based on yet to be defined extensions). I miss the Compelling reason. thanks alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 22:56: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 WAA12179 for ; Thu, 5 Oct 2000 22:56:38 -0400 (EDT) Received: from standards (47.234.32.16:4071) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E3BC@standards.nortelnetworks.com>; Thu, 5 Oct 2000 22:40:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28514 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 22:40:13 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E3B3@standards.nortelnetworks.com>; Thu, 5 Oct 2000 22:30:13 -0400 Received: from tropical.co.cr ([63.160.71.196]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id VAA23502 for ; Thu, 5 Oct 2000 21:44:38 -0500 (CDT) Received: from tropical.co.cr [63.178.136.109] by tropical.co.cr (SMTPD32-6.00 EVAL) id A20738010A; Tue, 03 Oct 2000 20:12:23 -0600 Received: from tv@yahoo.com by info@excite.com (8.8.5/8.6.5) with SMTP id GAA09654 for ; Wed, 04 Oct 2000 09:31:00 -0600 (EST) Message-ID: <> Date: Wed, 4 Oct 2000 09:31:00 EST Reply-To: 63426672@YAHOO.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: 63426672@YAHOO.COM Subject: [MOBILE-IP] cable services X-To: cable@yahoo.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > NOTE: THIS IS AN ADVERTISEMENT FOR LEGAL TV > > DE-SCRAMBLER. IF YOU HAVE NO INTEREST IN THIS > > INFORMATION PLEASE CLICK DELETE NOW. THANK YOU-- > > > > LEGAL CABLE TV DE-SCRAMBLER > > Want to watch Sporting Events?--Movies?--Pay-Per-View?? > > You can assemble from electronic store parts for about $12.00. > > We Send You: > > E-Z To follow Assembly Instructions. > > E-Z To read Original Drawings. > > Electronic parts lists. > > PLUS SOMETHING NEW YOU MUST HAVE! > > Something you can't do without. > > THE UP-TO-DATE REPORT: USING A DESCRAMBLER LEGALLY > > Warning: You should not build a TV Descrambler without > > reading this report first. > > Frequently Asked Questions--CABLE TV DESCRAMBLER > > Q: Will the descrambler work on Fiber, TCI, Jarrod > > A: The answer is YES. > > Q: Do I need a converter box? > > A: This plan works with or without a converter box. > > Specific instructions are included in the plans for each! > > Q: Can the cable company detect that I have the descrambler? > > A: No, the signal descrambles right at the box and does > > not move back through the line! > > Q: Do I have to alter my existing cable system, > > television or VCR? > > A: The answer is no! > > Q: Does this work with my remote control? > > A: The answer is yes. The descrambler is > > manually controlled--but very easy to use! > > Q: Can you email me the plans? > > A: No the program comes with an easy to follow picture guide. > > Q: Does this work everywhere across the country? > > A: Yes, every where in the USA plus England, > > Brazil, Canada and other countries! > > Q: Is this deal guaranteed? > > A: Yes, if you are unhappy for any reason we will refund your money. > > Q: When I order, when will I get my stuff? > > A: We mail out all orders within 48 hours of receiving them. > > ORDER INFORMATION > > ACT WITHIN THE NEXT 14 DAYS AND RECEIVE TWO FREE BONUS!! > > THE CABLE MANUAL! This manual contains hard to find information your > > cable company does not want you to know. Also receive The RADAR > > JAMMER PLANS! Never get another speeding ticket. Build you own > > radar jammer, this unit will jam police radar so they can't get a reading > on > > your vechicle. Radar jammers are legal in 48 states. It is simple to > build. > > The FREE BONUSES ALONE ARE WORTH ACTING NOW! > > THE CABLE DESCRAMBLER KIT COMES WITH A THIRTY DAY > > MONEY BACK GUARANTEE! IF YOUR NOT COMPLETELY SATISFIED, > > SEND THE CABLE DESCRAMBLER KIT BACK AND YOU KEEP > > THE BONUSES FOR FREE. YOU HAVE NOTHING TO LOSE > > ONLY FREE CABLE TV TO GAIN! ACT NOW! SIMPLY SEND > > $14.00 CHECK OR, MONEY ORDER. > > INFORMATION TO: > > > > NET SERVICES > > PO BOX 42013 > > URBANDALE, IA 50322 > > > > > > > > THIS INFORMATION IS SOLD FOR EDUCATIONAL PURPOSES ONLY! > > This mailing is done by an independent marketing co. > > We apologize if this message has reached you in error. > > Save the Planet, Save the Trees! Advertise > > via E mail. No wasted paper! Delete with > > one simple keystroke! Less refuse in our Dumps! > > This is the new way of new millenium! > > If you would like to be removed move233@dcemail.com > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 02:53: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 CAA26153 for ; Fri, 6 Oct 2000 02:53:27 -0400 (EDT) Received: from standards (47.234.32.16:1076) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E549@standards.nortelnetworks.com>; Fri, 6 Oct 2000 2:36:31 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29066 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 02:36:30 -0400 Received: from hermes.iaccess.com.au (203.5.74.7:4439) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E545@standards.nortelnetworks.com>; Fri, 6 Oct 2000 2:26:29 -0400 Received: from llama (as1-64.mel.au.asiaonline.net [210.215.17.64]) by hermes.iaccess.com.au (8.9.1a/8.9.1) with SMTP id QAA20285 for ; Fri, 6 Oct 2000 16:39:19 +1000 (EST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C02FBC.1A3C7220" 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 Message-ID: <001501c02f68$77acee20$4011d7d2@llama> Date: Fri, 6 Oct 2000 17:37:30 +1000 Reply-To: Craig Cameron Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Craig Cameron Subject: [MOBILE-IP] Evaluation of mobility management schemes To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C02FBC.1A3C7220 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] Are requirements required? Is this paper publicly available? I've had a look on Andrew's web page = and haven't managed to find it. http://comet.columbia.edu/~campbell/andrew/publications/publications.html= . Can anyone tell me where I can get it from? I've just finished implementing the interesting bits of HAWAII on MIT's = ANTS Active Network platform and am very interested in the differences = between Cellular IP and HAWAII. Craig Cameron University of Melbourne ----- Original Message -----=20 From: Hesham Soliman (EPA)=20 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM=20 Sent: Wednesday, October 04, 2000 8:19 AM Subject: Re: [MOBILE-IP] Are requirements required? WG in Pittsburgh, Andrew Campbell mentioned=20 that he was a co-author on a paper that did an evaluation / comparison = of the various=20 mobility management schemes. I've read that paper, and on the handoff = issue, it was=20 concluded that there were no significant differences between HMIP, CIP = and HAWAII.=20 ------=_NextPart_000_000A_01C02FBC.1A3C7220 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] Are requirements required?
 
Is this paper publicly available?  = I've had a=20 look on Andrew's web page and haven't managed to find it.
http://comet.columbia.edu/~campbell/andrew/publications/publica= tions.html. =20 Can anyone tell me where I can get it from?
 
I've just finished implementing the = interesting=20 bits of HAWAII on MIT's ANTS Active Network platform and am very = interested=20 in the differences between Cellular IP and =  HAWAII.
 
Craig Cameron
University of Melbourne
----- Original Message -----
From:=20 Hesham Soliman = (EPA)
To: MOBILE-IP@STANDARD= S.NORTELNETWORKS.COM=20
Sent: Wednesday, October 04, = 2000 8:19=20 AM
Subject: Re: [MOBILE-IP] Are = requirements=20 required?
 
WG in Pittsburgh, = Andrew Campbell=20 mentioned
that = he was a=20 co-author on a paper that did an evaluation / comparison of the = various=20
mobility management = schemes. I've=20 read that paper, and on the handoff issue, it was
concluded that there were no significant = differences=20 between HMIP, CIP and HAWAII. =
------=_NextPart_000_000A_01C02FBC.1A3C7220-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 04:50: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 EAA26799 for ; Fri, 6 Oct 2000 04:50:26 -0400 (EDT) Received: from standards (47.234.32.16:4193) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E5C0@standards.nortelnetworks.com>; Fri, 6 Oct 2000 4:33:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29227 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 04:33:52 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E5BF@standards.nortelnetworks.com>; Fri, 6 Oct 2000 4:33:51 -0400 Received: from esealnt406.al.sw.ericsson.se (esealnt406.al.sw.ericsson.se [153.88.251.29]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id e968mNt13579 for ; Fri, 6 Oct 2000 10:48:23 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Oct 06 10:48:23 2000 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id <4JBFDXK6>; Fri, 6 Oct 2000 10:47:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <5F05C89FB2F8D211B6430008C791912703EA81AE@esealnt190> Date: Fri, 6 Oct 2000 10:46:51 +0200 Reply-To: "Karim El-Malki (ERA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Karim El-Malki (ERA)" Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac hes To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Pete I would like to add something to Hesham's comments: > Again, this indicates a pretty tight real-time coupling between the > MIP client and the L2 that we wanted to avoid. Registering after > the L2 handoff removes this dependency. I think there is a misunderstanding here. We want coupling between the MIP agent (FA) and L2. That's the same for Proactive so I don't see a difference. Point 2) in the list of differences talks about this. > > In summary, I think the Fast Handoffs draft has some hidden costs > associated with it (tight L2 coupling, configuration of adverts from > neighbor FAs, getting "remote" registration to work properly) that may > not be immediately obvious on a first read-through. Both drafts involve costs on the network-side. That's all I think we can say and there's no "hidden" costs. In my view, a more appropriate question to be asked when looking at the two drafts is: should the MN be involved in the L3 handoff or not? > The Proactive > draft requires some extra support from the network elements but allows > us to use a completely vanilla (non real-time) RFC 2002 MIP client > implementation. As above, this is not a difference. I think that you can't claim to have a more RFC2002-compatible draft, maybe the opposite is the case given that in Proactive handoffs the network (FA) registers on behalf of the MN. > The frequency of advertisements/registrations can be > adjusted for optimum end-to-end performance without regard to the rate > of handoffs in the underlying L2 technology. Again, I think we can do this same adjustment, without relating to the rate of handoffs in the underling L2 technology. There is definitely no assumption that a L2 handoff will involve a L3 handoff. What we do is link the minimum rate of advertisement/registrations with the rate of L3 handoffs (change of FA) which is what RFC2002 does. This is different from Proactive, where there is no guarantee that a L3 handoff will involve an advertisement/registration. Regards, Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 06:42: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 GAA27857 for ; Fri, 6 Oct 2000 06:42:41 -0400 (EDT) Received: from standards (47.234.32.16:3144) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E6AC@standards.nortelnetworks.com>; Fri, 6 Oct 2000 6:25:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29394 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 06:25:55 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E63D@standards.nortelnetworks.com>; Fri, 6 Oct 2000 6:15:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27369; Fri, 6 Oct 2000 06:30:27 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200010061030.GAA27369@ietf.org> Date: Fri, 6 Oct 2000 06:30:27 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-hmipv6-00.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 : Hierarchical MIPv6 mobility management Author(s) : H. Soliman, C. Castellucia, K. Malki, L. Bellier Filename : draft-ietf-mobileip-hmipv6-00.txt Pages : 16 Date : 05-Oct-00 This draft introduces some extensions for MIPv6 and neighbour discovery to allow for the introduction of a hierarchical MIPv6 mobility management model. The proposed hierarchical mobility management for MIPv6 will reduce the amount of signalling to CNs and the HA and may also improve the performance of MIPv6 in terms of handoff speed. Moreover, HMIPv6 is well-suited to implement access control and handoffs between different access technologies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-hmipv6-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-ietf-mobileip-hmipv6-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-hmipv6-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: <20001005145804.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-hmipv6-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-hmipv6-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001005145804.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 09:32: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 JAA03420 for ; Fri, 6 Oct 2000 09:32:08 -0400 (EDT) Received: from standards (47.234.32.16:2817) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E864@standards.nortelnetworks.com>; Fri, 6 Oct 2000 9:15:28 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30073 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 09:15:28 -0400 Received: from sirius.ctr.columbia.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E863@standards.nortelnetworks.com>; Fri, 6 Oct 2000 9:15:27 -0400 Received: from comet.columbia.edu (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id JAA11295; Fri, 6 Oct 2000 09:29:52 -0400 (EDT) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <001501c02f68$77acee20$4011d7d2@llama> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39DE01F6.5C4F794B@comet.columbia.edu> Date: Fri, 6 Oct 2000 09:46:46 -0700 Reply-To: campbell@comet.columbia.edu Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Andrew T. Campbell" Organization: Center for Telecommunications Research Subject: Re: [MOBILE-IP] Evaluation of mobility management schemes X-To: Craig Cameron X-cc: cellularip@comet.columbia.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Craig: The paper is still under review for a conference. We will release the paper and the NS code for used to compare CIP, Hawaii and HFA. We could also submit this to the working group as a personal ID. Or if its deemed out of scope to the new WG. We can do that for the next meeting. Thanks for your interest. Andrew From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 09:39: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 JAA03591 for ; Fri, 6 Oct 2000 09:39:53 -0400 (EDT) Received: from standards (47.234.32.16:2817) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E8B6@standards.nortelnetworks.com>; Fri, 6 Oct 2000 9:23:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30065 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 09:23:19 -0400 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E85C@standards.nortelnetworks.com>; Fri, 6 Oct 2000 9:13:09 -0400 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id GAA02927 for ; Fri, 6 Oct 2000 06:27:17 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id GAA16849 for ; Fri, 6 Oct 2000 06:26:37 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Fri, 6 Oct 2000 08:26:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: Date: Fri, 6 Oct 2000 08:26:06 -0500 Reply-To: Roberts Philip-qa3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Philip-qa3445 Subject: Re: [MOBILE-IP] Are requirements required? X-To: "charliep@IPRG.NOKIA.COM" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Charlie, > ---------- > From: Charles E. Perkins > Reply To: charliep@IPRG.NOKIA.COM > Sent: Thursday, October 5, 2000 5:54 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Are requirements required? > > Hello Sandy, > > > There is no question about the following statement > > you make regarding Mobile IP: > > > "as it's currently > > > defined will have trouble completing a "handoff" in > > > time to keep from noticing a glitch in service if > > > it's being used to support a realtime service." > > I would like to raise a lot of doubt about this statement. > > There is nothing in Mobile IP that prevents the mobile > node from knowing _EXACTLY_ when to register a new > care-of address. > > There is nothing in Mobile IP that _ASSURES_ that the > mobile node discovers exactly when to register a new > care-of address. > > Mobile IP does NOT OFFER A SOLUTION for notifying > the mobile node about the completely optimal time > when to register a new care-of address. The solutions > provided are not meant to stand in the way of any other > better solution that might be available. > > A mobile node IS ALLOWED, by any means deemed expedient, > to discover when to register a care-of address. > > This has a much different truth value than the quoted > statement above. > > For example, suppose a mobile node hears an advertisement > (from another protocol) 1000 times a second, that contains > a care-of address, it will be able to execute perfectly > smooth handovers. Just as an example. No one says you > have to do it this way, and no one says you cannot do > it this way. The protocol says you cannot issue RFC 1256 > Router Advertisements this often, but nobody says you > cannot do it another way. > > Bottom line is that a mobile node, using Mobile IP, > _possibly_ but _not necessarily_ in conjunction with > other protocols, _MAY_ be able to execute a perfectly > smooth handover without any glitches. > > Maybe I didn't say this the right way or the politically > correct way, but I hope it is clear. It's a little > frustrating over the years to hear Mobile IP be so often > dinged for not doing a thing it was explicitly designed > to avoid doing. The whole point was to enable the > development of link-specific or system-specific solutions > since no general methods seem to be widely agreed upon > as applicable. Link-specific and system-specific solutions > have more limited interoperability, but that is just the > way it is. > I think I've digested all the wording here and I think I agree. Perhaps if I'd said "Mobile IP as it's currently defined wil have trouble ... on a lot of systems in which people seem to be interested in using it" you would have been more sympathetic? No doubt one could send 1000 advertisements a second in some systems, but probably not in most cellular systems. And no doubt one might be able to implement a link layer that could be engineered to automatically generate an advertisement at a mobile without sending it over the air. Might we also agree that the number of proposals being generated in the working group to improve handoff performance gives the impression that maybe some things could be done to modify MIP to make it a little better for this in the context of some real systems? > Regards, > Charlie P. > Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 09:48: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 JAA04469 for ; Fri, 6 Oct 2000 09:48:54 -0400 (EDT) Received: from standards (47.234.32.16:2817) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E90F@standards.nortelnetworks.com>; Fri, 6 Oct 2000 9:32:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30291 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 09:32:24 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E90E@standards.nortelnetworks.com>; Fri, 6 Oct 2000 9:32:24 -0400 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA17888 for ; Fri, 6 Oct 2000 07:46:56 -0600 (MDT) 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 GAA24413; Fri, 6 Oct 2000 06:46:56 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id GAA13287; Fri, 6 Oct 2000 06:46:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Fri, 6 Oct 2000 06:44:47 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac hes X-To: "Karim El-Malki (ERA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <5F05C89FB2F8D211B6430008C791912703EA81AE@esealnt190> > > > The Proactive > > draft requires some extra support from the network elements but allows > > us to use a completely vanilla (non real-time) RFC 2002 MIP client > > implementation. > > As above, this is not a difference. > I think that you can't claim to have a more RFC2002-compatible > draft, maybe the opposite is the case given that in Proactive handoffs > the network (FA) registers on behalf of the MN. Only within its own infrastructure. The I-D does not allow the FA to register with the Home Agent on behalf of the Mobile Node. Given that the Mobile Node has already registered with its Home Agent through the Foreign Agent, the local network simply "extends" the registration through another Foreign Agent that it also owns. So, there are no changes to the mobile node, or Home Agent. 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. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 10:02: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 KAA04830 for ; Fri, 6 Oct 2000 10:02:20 -0400 (EDT) Received: from standards (47.234.32.16:2817) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E974@standards.nortelnetworks.com>; Fri, 6 Oct 2000 9:45:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30351 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 09:45:46 -0400 Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E93F@standards.nortelnetworks.com>; Fri, 6 Oct 2000 9:35:46 -0400 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id GAA08787 for ; Fri, 6 Oct 2000 06:50:19 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id GAA07945 for ; Fri, 6 Oct 2000 06:50:18 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Fri, 6 Oct 2000 08:50:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 6 Oct 2000 08:50:16 -0500 Reply-To: Roberts Philip-qa3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Philip-qa3445 Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt X-To: Steven Glass - Solaris Software To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > ---------- > From: Steven Glass - Solaris Software > Reply To: Steven Glass - Solaris Software > Sent: Thursday, October 5, 2000 2:03 AM > To: Roberts Philip-qa3445 > Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] FW: I-D > ACTION:draft-jaseem-rap-cops-mip-00.txt > > > I thought the AAA working group had already eliminated COPS as a AAA > > protocol. If so, please explain why we should be considering COPS in > MIP? > > I know this is going to get dinged by many of the people I work with > (on > this list, and in the office), but is there some reason the authors can't > have > an individual submission for an informational RFC? RFC2356 comes to mind > (use > of SKIP FW traversal in Mobile IP), published by the mobile ip working > group > in June 1998, after the decision of the IPSec WG (and Jeff Schiller) for > ISAKMP/Oakley as the IPSec protocol of choice. If the authors want to > work on > this, it doesn't have to be an official working group document (hence the > name > d-jaseem-..., not d-i-mip-...) to get some review from mobile ip WG > members > willing to read it (if any, and presuming it works). If the authors want > to > move it to anything more than informational, however, it seems likely to > be > blocked by the IESG... > > Cheers, > Steve > Steve, I agree 100% with what you've written. Anyone can submit a personal draft to this working group and advertise it on this list to get feedback. My statement was too strong. I should've asked about the authors' intent before making the assumptions I made. Phil > > > ---------- > > > From: Muhammad Jaseemuddin > > > Reply To: Muhammad Jaseemuddin > > > Sent: Wednesday, October 4, 2000 9:10 PM > > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > > Subject: [MOBILE-IP] FW: I-D > ACTION:draft-jaseem-rap-cops-mip-00.txt > > > > > > We have submitted a draft defining COPS usage for Mobile IP. The > > > announcement is attached below. We will appreciate any comments. > > > > > > - Muhammad Jaseemuddin > > > > > > -----Original Message----- > > > From: yaniv@iphighway.com [SMTP:yaniv@iphighway.com] > > > Sent: Wednesday, October 04, 2000 7:19 AM > > > To: rap@iphighway.com > > > Subject: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > > > > > To: IETF-Announce: ; > > > CC: rap@iphighway.com > > > From: Internet-Drafts@ietf.org > > > Reply-to: Internet-Drafts@ietf.org > > > Subject: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > > Date: Wed, 04 Oct 2000 06:54:46 -0400 > > > Sender: nsyracus@cnri.reston.va.us > > > > > > --NextPart > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > > > > > > Title : COPS usage for Mobile IP (MIP) > > > Author(s) : M. Jaseemuddin, A. Lakas > > > Filename : draft-jaseem-rap-cops-mip-00.txt > > > Pages : 14 > > > Date : 03-Oct-00 > > > > > > Mobile IP is a protocol that is used to achieve transparent routing > > > of IP packets to a mobile node. A mobile node obtains a care-of- > > > address in the foreign network and registers that address with the > > > home agent. The home agent as well as the foreign agent can apply > > > policies to the mobile node registration. This draft defines COPS > > > [1] usage for Mobile IPv4 [2]. It describes how COPS is used to > > > control Mobile IP registration based on policies. It defines the > > > interactions between the PEP and the PDP to handle Mobile IP > > > registration messages. It also provides a guideline for mobility > > > agents on how to use this COPS client with regards to the > > > registration messages. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-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: <20001003122806.I-D@ietf.org> > > > > > > ENCODING mime > > > FILE /internet-drafts/draft-jaseem-rap-cops-mip-00.txt > > > > > > --OtherAccess > > > Content-Type: Message/External-body; > > > name="draft-jaseem-rap-cops-mip-00.txt"; > > > site="ftp.ietf.org"; > > > access-type="anon-ftp"; > > > directory="internet-drafts" > > > > > > > > > --OtherAccess-- > > > > > > --NextPart-- > > > > > > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 10:18: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 KAA05024 for ; Fri, 6 Oct 2000 10:18:09 -0400 (EDT) Received: from standards (47.234.32.16:2817) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9EA01@standards.nortelnetworks.com>; Fri, 6 Oct 2000 10:01:31 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30511 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 10:01:30 -0400 Received: from stargate.ipunplugged.com (195.42.212.161:24980) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E9B9@standards.nortelnetworks.com>; Fri, 6 Oct 2000 9:51:28 -0400 Received: from FREDRIKJPC ([192.168.4.218]) by stargate.ipunplugged.com (8.9.3/8.9.3) with SMTP id QAA29091 for ; Fri, 6 Oct 2000 16:04:17 +0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0000_01C02FAF.8916D0D0" 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.2919.6700 Message-ID: Date: Fri, 6 Oct 2000 16:07:33 +0300 Reply-To: Fredrik Johansson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fredrik Johansson Subject: [MOBILE-IP] Challenge / Response with co-located FA To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C02FAF.8916D0D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_01C02FAF.89185770" ------=_NextPart_001_0001_01C02FAF.89185770 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit BlankHi I have a question concerning how Challenge / Response is supposed to work when a mobile node registers using a co-located foreign agent. Since the mobile node does not receive an advertisement with a challenge from a FA it cannot calculate a response to be used in a MN-AAA Authentication extension, i.e., the Home Agent cannot use a Radius server to authenticate the MN. Have there been any thoughts in this area, or perhaps a solution in an earlier thread that I've missed? Thankful for any pointers. Regards /Fredrik ----------------------------------------- Fredrik Johansson W: +46 (0)8 725 5916 M: +46 (0)70 786 5035 mailto:Fredrik.Johansson@ipunplugged.com http://www.ipunplugged.com ------=_NextPart_001_0001_01C02FAF.89185770 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Blank
Hi
 
I have a question concerning how = Challenge /=20 Response is supposed to work when a mobile node registers using a = co-located=20 foreign agent.
 
Since the mobile node does not = receive an=20 advertisement with a challenge from a FA it cannot calculate a response = to be=20 used in a MN-AAA Authentication extension, i.e., the Home Agent = cannot use=20 a Radius server to authenticate the MN.
 
Have there been any thoughts in = this area,=20 or perhaps a solution in an earlier thread that I've missed? Thankful = for any=20 pointers.
 
Regards
/Fredrik

-----------------------------------------
Fredrik = Johansson

W: +46 (0)8 725 5916
M: +46 (0)70 786=20 5035
mailto:Fredrik.Johansson@ipunplugged.com
http://www.ipunplugged.com

 

------=_NextPart_001_0001_01C02FAF.89185770-- ------=_NextPart_000_0000_01C02FAF.8916D0D0 Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: <565580313@06102000-2cba> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCABnAt4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9U6KK KAEZgilmICgZJPQCvO9b+PvgzQ7x7Z9Re8lQlWNnC0iqfTcOPyNYv7S3iqfQ/Btvp9tMYZdSm8t2 Q4by1GWH48CvlgDAwBgegqW7HJVrOD5Yn2x4G+KGifEOa7j0g3LG1CmRp4SgGc4A9TxXXV86fs/e NPC3gvwzfHVdYt7O/u7nc0UmdwRQAvQfWvU/+F3eB/8AoY7T/wAe/wAKEzSnUTinJq53Feb638f/ AAloGr3em3U12bm1kMUhityy7h1we9XpPjh4ISN2HiC1cqCQqhsn2HFfHmp3zalqd3duSXuJnlJP XLMT/Whu2xFWtypcjPqj/hpbwX/z0v8A/wABD/jR/wANLeC/+el//wCAh/xr5OzRmo5mc31iZ9Y/ 8NLeC/8Anpf/APgIf8aP+GlvBf8Az0v/APwEP+NfJ2aM0+Zh9YmfWP8Aw0t4L/56X/8A4CH/ABo/ 4aW8F/8APS//APAQ/wCNfJ2aKXMw+sTPrH/hpbwX/wA9L/8A8BD/AI0f8NLeC/8Anpf/APgIf8a+ TqKfMw+sTPsjwz8cfCPinUY7G1v3gupTtjju4jH5h9ATxn2zXfV+f1orvd26xZ80yoE29d24Y/Wv vu0VltIQ+d4RQ2fXHNUnc6qNV1L3JqKKKo6QooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooA+W/2n9aN743stPByllahiP9pzn+SivHWO1SfQV1PxS1r/hIPiHr16G3Rm5aJD/sp8g/9B/W s/wZop8ReLtH00DIubpFYf7IOW/QGsnqzx5vnmz6o8E/Cbw5B4Q0ddQ0Oyub77LG00ssQLM5GTk/ jW3/AMKr8If9C5p3/fgV1KqFUAcAcYpa0sj1VCKVrHkPxi8IeFfCnw81W9ttBsILsqIoZEhAKuxA BH61H8I/hJ4dvPh9pN3q+j217fXSGdpZlJbaxJUf984rP/aivnudO8PaFAczX13nYO+BtX/x5hXt GlWKaZplpaRjCW8SRKB6KAP6UramKipVHpscv/wp3wV/0Llj/wB8H/Gj/hTvgr/oXLH/AL4P+Ndl VW/1Wy0pEe9vLezVzhWuJVQMfQZNOyNuSPY5f/hTvgr/AKFyy/74P+NH/CnfBX/QuWP/AHwf8a2/ +Ew0H/oN6d/4FR/406PxXokzhU1iwdj0C3KEn9aLIXLDsjAf4M+CZFwfDlmPopH9ax9U/Z38Faij COwlsXPR7aZhj8CSK9LVg6hlIZTyCOhpaLIbpwfQ+U/iT+z7qPg2ym1PTLltW02L5pEKYmiX1IHD D3GPpXkoORntX6COiyIyMAysCCp6EV8MePNITQPGut6fEAsVvdyKijoFzkD8jUSVjgr0lCziaPwl 0T+3/iNoVqy7o1nEzj/ZQFv6V9sV8x/staOLrxXquosMi0tRGhx0Z2/wX9a+nKqJ0YdWhfuFFFeC fE/9pa78B+N9Q0K10a3vY7TywZ5JmUszIrkYA7bsfhVN2NK1aFCPNUdke90Vi+C9dm8T+EtI1e4h S3lv7WO5MUbFlUOoYYJ9iK2qDVNSV0FFFeb/ABV+Num/Cq+sLW7sZ76W7jaUCBlGxQQBnPqc/kaC J1I0o803ZHpFFcx8OfHMPxF8MRa3b2ktlBLI6JHMwLHacE8e+fyrp6CoyU0pR2YUUUUFBRRRQAUU UUAFFFFABRXMfEbx7afDfwxLrV5A9zGkiRLDEQGdmOOM8dMn8K5/4VfGqy+K17fwWWmXNkLONXeS d1IO4kADH0P5UGTqwU1Tb1fQ9Hor5t+Lf7RviLwZ4/1TRdJh097Oz8tQ9xC7OWMas3IcdCxHTtXu fgHWL3xB4K0TVNRES3l7aR3MghUqg3jcMAk9iKV7mdPEQqzlTjutzfooopnSFFFFABRRXLfE3xof h94I1HXVgW6ktvLCQM20OzOqAZ/4Fn8KCZSUIuT2R1NFfLX/AA2Lqn/QuWf/AIEP/hW34Q/a6ttQ 1aK11/R1061lYL9stpi4izxllI6epB49DSujhjj8PJ2UvwZ9FUU1HWRFZWDKwyGU5BHrTqZ6AUUU UAFFFFABRRRQAUVyPxV8ct8OfBN7rkdul3NC8aRwSMVVyzhTyPQEn8K4j4L/AB11L4qeJLvT5tGg sba2tTO08UxY7t6qq4I75J/4DSuYSr04VFSb95nstFFFM3Ciimu4jRmYhVUZJPYUAOor5hg/a71W +v47a18N2jNNII4vMuHGSTgZwD7V7v8AEvxl/wAK/wDBOpa6IVuHtQmyF2IDszqgGR/vfpSuctPF UqsZSi9FudPRXlHwQ+M178WbnV0uNMgsI7BIjuilLli5fAwR/sGvV6e5tTqRqxU4bMKKKKDQKKKK ACivKPjd8ap/hRc6RBa6dDqEl6kruJZSmwKVC4wDnOW/Ktv4NfES9+J3hafWLzT49OC3TQRpE5cO qqp3ZPuxH/AaVzBV6bqOin7yO8ooopm4UUVFc3MVnbyzzyLFDEhd5HOAqgZJJ9AKAJaK8q8M/tGe HPF/jO28PaZaahNJcOyR3bRqsTbVLFsbt2MKeo/CvVaDOnUhVV4O4UVyvxC+JOjfDPSEv9XkkPms Uht4FDSSsBkgAkDjuSQOnqKh+GfxMsPijo9zqOnWt1awwTm3ZboKCWCq3G0kdGFAe1hz+zvr2Owo oooNAoopCQoJJAA7mgBaK+bdG/av1HXPE1hpdvoFp5d5eR2sUrTuDh3CqcbevI4r6SpJ3MKNenXT dN3sFFFfNvib9rebTPEGoWmm6LbXtjBM0UVy87AyhTjdgDoSMj2xQ3YVavToJOo7XPpKiuN+Evj9 viV4Ng1mS2jtJmlkikhjfcFKnjn6EH8a4r4z/H64+F3ia10m10uHUDJarcu8spXaS7KF4H+zn8RR cJYinCmqrfus9nor5a/4bF1T/oXLP/wIf/Cu/wDhJ+0da/EXXY9DvtMOmalMrNbtFIZY5SqlmHQF TgE85Bx1zgEujGGOw9SSjGWr9T2aiiimdwVk+LNYXw/4Z1TUmOPsttJKPqFOP1xWtXmP7RWt/wBk /DS7gVsSX0qW4HqM5b9BSeiIm+WLZ8kM7SEs5yzHJJ7k9a9T/Zt0c6l8SFuiuY7G2eQn0ZvlH9a8 rr6R/ZW0TyNE1jVmXm4nWBG/2UGT+prNbnmUVzTR7rRRSMwVSSQAOST2rU9Y8E8UH/hMv2k9H08f vLfSIlkcDoGALn9Sn5V75XgfwFB8SfEjxl4jcFw0hjjc9gzkgf8AfKrXvlSu5hS1Tl3YV81/tVav 9o13RNLBBWCB7hl9GY7R+imvpSvjP4y6rL4k+JmtzRJJPHbyC1UxqWACDHb33US2IxDtC3c4TYv9 0flRsUn7o/KrAsbr/n1n/wC/Tf4VoaT4P13XLlILDSL24kc4GIGC/ixGAKzPNSufSP7Mc15N8P5/ tEryW6XrpbhznaoVcge24n9a9ermPhr4SPgjwVpukSMrzwoWmZehkYlmx7ZNdPWq0R7FNOMEmFfD fxFvxqfj3xBcjG172TGOmAcf0r7J8a+IIvCvhTVNUlOBbQMy+7Ywo/PFfCs00kpklclpXJdj6seT +tTI5cS9kfUn7MOifYPAlzfsuHv7pmBPdEG0fqG/OvYa5z4c6KPD3gXQ7ADBitU3e7EZJ/M10dUt jqpx5YpBX5/fEu/fxB8SvEU8YMjTajMkSjqwDlUH5AV97avqCaTpN7fSY2W0DzNn0VST/Kvgn4Ya a+vfErw5bN+8MuoQvJu7qrhn/QGlI8fM/e9nTXV/1+Z7/wDtAfEfXfhbF4W0fw7qK2DLaN55EMcp ZV2InDqcDh+nX8K86l+NfxT1Xwa99FLcDT7aYi41iGzRck4AQsFCgAkdBnLDJ5AqL9qjVRqHxWlt wxP2GzhtyPQkGT+UgrtvGWzwt+yZoVkp2/2n9nIKnO4yObnr9F/p0pHPUnOpWrWm0oro+w79nP4y +I/Evim40PW7s6pBJbvPFLIoEsbLjgEAZBBPB9sV4n8S/EXifxD4nc+LTKmq2saw+RLEsZhQ5dVw oA6PnJGSCPavUf2QNINx4x1rUiCVtbEQ+waRwR+OIz+teZ/FrUjrnxR8Sz5VA2oSQqznau1G2An0 GFBoexz1pTnhIOUm7t/P/hj2P4I+KPEvw98KX194oW5s/B9hYeZYW0lsiedJLIGXY20MxO5upx8+ T045m3+MXxL+LPixbDw5P/Z27dIlpaBQkUY/ikkYZOMgEnAJxgAnFd9+1IsUXws0S3sZlms7bUIo WMLAqNsD7Qce38x7V5B8D/A+seNNT1RdD8Tv4bvLaFCxhlkSSaNic42EHaCFz9VofY6KrqU6kMLB tpeer+Z13hL4/eLvAXjJ9F8aTG+tYp/IuhKqmW3OeXVl+8BnODnI6Yr1T9o74i6r4B8LaXLoV6tn fXd3t83y0kzEEYsAHBHUpz/jXgdz8PNG1zxLdWt58SrW51gzmGSS6tp3Mrg7f9achuRgc9vpXVft Y3f2W/8ACWhlwzWNg0jbeAdxCZ/8hGi+hSrVqeHqcz9NU3v3RzEv7S3jmbQpLJtUzeSS7jfCCJXW PAARQqgDnJJxnpgjmvVPFvxW8b+HPAHhhNJ0m9v7+802K6vNals2lSNnUMFGF27+ed3A6YPONX9l fwjY2Hw+TWzbRPf6hPIftDLlljRigUHsMqx49favGfih8ePEvibxBe2unalcaNo8MrQwW9pJ5LMo JG53BB57jOB6dSTZBzzoUFUqVHeS0/plrV/F/wAY9F8PweIdQvtRtNLnZdk8giXJPK5TGQD2yADX rP7Onxl1f4gyajpWumOe6s4VnjvEQIXTO1g4HGckYIA714t8Yvh7eeANO0n+1/FEmta1fFnltCzM sKAA53MxLfMTgkDPPHBrof2etMuU8EfErVbXctymlPb2zRjL+Z5Ujce+QlCepFGpVp4lQbe2qbv0 uWfij+0trer65NpnhCb7Hp8cnlJdQoHmumzjK5BwpPQAZPrzgY+mfHb4hfD3xMLfxHJcXiIVNxp2 oRKrlSAcqwGVODx29Qa434OJZv8AFHw19vkjitlvEcvL90MuSmf+BBRX0d4n+I/wnvfHdzZ65p8F /qVvstzfSWQuonPXYu3cSQTg/L1yKNxUp1a6dZ1eV3stdPuPKf2j/G2v67qkNuzTJ4OuxDe6XuhV VnPkIWcPjccGUjGSOR7Yr/s6ReM7bxHayaHHcQ+H7y8iTUrlLZHjdY8sULspK8OR8pH3vWtL9rO5 ht/Fmg6NawR29pp+mqYooUCJGGdlCqBwAFjXAHFeofAvUbTwz8BVvVuITPFb3l/KkbhmXYz8kewV c/lR1LhTdTGyvJ+7r+WnoeMeJvjz41n8Yapb6XqkQtmvpYrWIWVs/wAnmEIu4xknjAyTzXZ/Hf4n eOfhx43Sw03XWh06ezinhQ2cDBTgowBMZPLIWxnjd2GK8b+FGlHXPiZ4atT8wa/ikcNzuVG3sPxC mvdv2w9BM2j+H9ZRf+PeeS0kIHUOoZc/Ty2/76o6GVOdWph6lXmd7rq/n+Z1Nl8ZZbL4A2/i69lW bV3ia3TcqjzLoOyA7RgY+XeQMcA1xngL41eJNI8C6r4w8W6k2p2rSCy0vTxBDD9on6s25EBCgDGe R97gkCvDNKvtZ8W2Gi+DLVjLCb5pLeLnHmSBVyfZcMc9tzV6t+034aj8HaB4D0W03mxsre4iVjwH f90WY+5JJ/E4ouarFVZwdaLdoJL1b6+dijoHxE+LPxb1q7GhX7RfZ4/MeK1WOGCEHouWySSQcZJP XsDjoPg5+0Jrq+LLfw34tlF2lxN9lS6dAssEudqq20AMC3GTyCc5xXIfBb4fa74q0LVdQ0Xxo/hl LeUJcwwzyRkqF3LI+1gNvLAE+jU3wV8O9C8ReLbFrXx9Z32o/a1lME9nOkk7B9xwzDDE9c5PWhXM qU8QuSabu+7Vn6K59n14j+1tqhs/hzZWin5rvUEDD/YVHY/rtr26vmD9sbUxJqfhnTw3MUM87L67 2VQf/HG/Oqex7WOlyYeb/rU4T4EeJfB/hfUdZuvFscU8clusMEM1n9oD5bL8YIHRRz1zXG+ONQ0r XfGOpXXh+waw0u4mBtrQKAVGADhRkDJyQo6ZwK9a+B/wA0b4j+D5dY1i71G2kN28MK2ciKpRVXk7 kbncWH4V7N4I/Z58IeBtTj1G3hudRvYm3RTahIr+UfVVVVXI7EgkVNmzxaeEr16UINJR3v1PNviD 8ddS+G/h3Q/COk+Wdfs9Ot4tQvZv3vkSCJQUUHhnzyScgdMEk45G68X/ABg0XwpZ+LrjVrpNJuJA Y3k8pshvusYyPut24x09RXnPxH83/hYXibz93m/2nc7t/XPmtXqnjL4Zah4f8J6e/iD4ns+hXXlp bwE3FxCy7cqVjDHKgAYIHHHtRuJ1a1aU2m7R2s7W7XPafgb8XP8AhaPh+5a8jjt9WsGVblY+EdWB 2yDPTOGBHYj3FePfEz9pnXNX12XTPB8gsrBJTDHdRxrJNdHOMrkEKpPTAzz15wNX4WeCLXw74F8e 6pofiS21/wA/R54UNnC8bxSCNyvDc5Ppj0rx/wCDNtb3fxU8MR3TKsQvUfL9Cy/Mo/FgB+NDbN6t evyUqbdnLd/O26OwvPi98Ufhj4hitteupHmMazGyv0jkSSM5AO5eRyCOCOQQemK+i3+JkOsfB6+8 YabmBxp800aPgmKdVYbTkYOHGM45HOOa+df2rNai1T4nrbQyBxYWUdvIBghZCzuefo6/lXRzG48N fsjLHODBLqlwPLBHJRptw/76VCfoaE7FUa06VSrT5m4xTevkc54O+PPxO13xFa2Nnef23czB1SyN rAgdtjYJIRSApwx5HA61Ut/jt8Q/Bnit49Zv5rmW1mKXenXaIFbB+ZflX5fYrx06jrq/sk2kMvxE v7mWRFa306QojYzkugLD6DP51518T9cHin4i6/qEBEsU966wsh3b0U7EI+qqPzpHC6lWNCNX2ju3 3PoD9qjxNBqfwy8ONaSFoNUuY7uNhj54hExH/oxT+FYn7J622g6J4w8R38ggsoFiRpWH3VRXd/r1 Tj+dcz+0csmkWXgDw5cENdaVokYlwONxCxnH4wmtPR9Jk0/9kjWrmINm/vlncqOdizxR4+mY/wBT 70+p2ObeMlUa+GN/w/4JU139oDxx8RfFUWl+Ey2mQzy+Xa2tuqmaQddzuw44BJxgAZznGacPjL8R PhL4wOneKZ/7UjQq81rNsbcjfxRyKMg46ds9RXB/B/wrqHi/xkljpWunw9qCwSSxXSO6OxGAUUqQ clST16A10nivwBp7eKrjT/EXxNhn1iDbE8t7BcTY4yF805AxnoTxn60anNGpiJw9qpO9+6S9LH2N pGq2+uaVZ6jaP5lrdwpPE5GMqwBH6GsX4laq2ifD7xHeocSQ2ExjOM4coQv6kU/4eaF/wjPgjRdM +0Jdi2tlQTxqQsg6hgD65rk/2kriS3+DmueWcb2gRj/smZM/4fjVH0dSbjRc3va/4Hyl8INKOs/F DwxbDoL6KYj1WM+YR+Smvo79rTVjZfDe1s1PzXt/GrDPVFVmP/jwWvCP2ftb0jw78T9Pv9Zuo7K3 jilWOeXhUkZCoycccFhn3rr/ANqf4gaV4s1PRNP0fUIdQhsUlkmltmDxl3KgAMOCQEPTj5vylbHz 1CcaeCqa6t/5G18Crubwb8CvGniSFhBdl5BbyNtI3JEojbByD87ng9cVyPhX4/8AxO1bWEtLS6bX LqVGWO0FlFycfeOxAfl69QOOeM11fiW3fwf+yZpVlN8k+qyxsdoxuEkjTrn/AIAij8Kp/seaUtx4 o8QaiQC1rZxwA56eY+en/bL/ADzR5Gq9oqlGhCTWmtvvOMg+PXxD8Pa+Tf6tPLPbSlZ7G8hUKSDh kZQo29McYIr3/wCPnxL1Xwd4A0jUtDuRYX+oXEYDlEk2xmNmYYZSDztHSvlO/ZvHHxCuDGzM2r6o 2xhjd+9l4x2/ir2r9sPUgL/wxpcZ2rDDNOUHoxVV/LY350J6EUq1SNCtLmbtZLUwfDnxg+LHi3Qt cGmzSal9mRJZbyK3gRrWMbywUBRlmwPU4U4GeRo/BH4/+IZ/Gtjo/iHUDqVhqMgt0kmVQ8MrcIQQ BkFsLg+uR77PwM1S28IfALxbrTTRi482faCdpDiJFiQ85yWPH+9XjXwb0efW/il4Ygtx80V/FcsS MgJEwkb9EI/GgXPVpui1Nty6X8ztv2sdT+2/E2G2DHbZ2EUZXsGZncn8mX8q9C0XWL74Y/ss2upW EottUlAlhlKKcGW44OGBB/dnuD0/Lwz43aour/FjxPcKchbswE+8SiL/ANkr2T9o5P8AhGPg54O8 PKSjK0KMNuNwigKnP/AmB+tHcuE37TEVl0TX+X5B+zv8VPGXj/xxcWes6v8AbNPgsnnaP7NDHlt6 KvKID/ET17VxWu/H3x9ceN9Q0/S9dENs+oyW9pH9kt2CIZSqDJjycDAya1P2Z9c07wdoPjXxBf3c MJt4YliiaRQ7kCRtoXOSSdoH415x8HdLOufFTwzbuzOftyTsWOS3l/vDknrnbzQZurUdKlFTd5N9 fOyPob9of41an8O57HQ9DZYtSuIPtEt5NGHMcZLKu0EbdxKtnIIGOnPHlGuah8UL74Xv4l1LXnk8 PX5MDwNIokdGJTJUL90nI659sVb/AGlPFWi+NPHdtpmnQGLU9PkNhc6lcTLHCcMfkOegRmbLkjHz cEYIqD4deJ9c8M2Wjf8ACfeGLrRIJC0FuNZVolbJ7hTnBJ45xk4FDNa86lWrUUW2lorPS/md1+yg ugazZ3IbQreLXtHcSLqYyXkWUOvUnggBlwOMEcZzXI+IPj940+IHjGLTPC12dMtLm5EFnDDGqvIC cK0jsCR6nGAB1HGa9g8BeDdI/Z48AarrWoXhv5XRJru5t14cA4jjjBPcvjJIyW5wMY+ZtA0xfEfj G81Dw7qWm+EI4LhZrJNV1JIWQlvlVGIG4gjoBwCAc9SbaFVXUo0qVK9n1S0dv+GNH4pTeKtC8ZWF l42u4/EEtiFnSFpSYpI2ILLkBSAduD0PFfSNx478MfC34U2viLTNIisINUSO5t9MhwhlnkjU4JAO MBRlsdF75GfH7D4Ea58QvFpude8ZaNfSSkNcSWd6Li4ZRjhU2gDgY9B6GtD9rLSo9DsPBGnWaNFp 1pbzwQpnIAURAZPc4A6/40bahB1cPCrXt6X1fYxdA+InxZ+LetXY0K/aL7PH5jxWqxwwQg9Fy2SS SDjJJ69gcdB8HP2hNdXxZb+G/Fsou0uJvsqXToFlglztVW2gBgW4yeQTnOK5D4LfD7XfFWharqGi +NH8MpbyhLmGGeSMlQu5ZH2sBt5YAn0am+Cvh3oXiLxbYta+PrO+1H7Wspgns50knYPuOGYYYnrn J60K5jSniFyTTd33as/RXPbvj/8AGqX4b2kGl6RsbXbxPMEjgMttHnG/aeCSQQAeOCT6HxjQ/iP8 WJPD974kSe61PQYg8M8lwiGPkYJAGG+UkHcvAI54yKxf2i7mW5+MWviViwiMMaA/wqIU4H5k/jXq /ivUbPwr+ylpNnbTIsup28MaBG5Z3cSyj/0MH8qL3NZ1Z1q1R87Sgnt5HkX7P2mf2r8XvD0ZUlIp XnYjtsjZgf8AvoAfjX3RXyP+yLpRuvH2pXxGUtbBlB9Hd1A/RWr64px2O3LI8tC/dv8AyPNvj/47 /wCEG+Hd40MmzUdQzZ22OoLA73Hphc8+u2vjuTwhdw+CY/E0nyWc199hiUjl2CFmb6cY/P0r0D9o 3xlN46+JJ0qwD3Ntph+xQRwguZZiR5hAHfdhMDrsHrXJ6/deNo/Bdnomq2N/a+HNPmE0MU2neSkc h3DJfYCSfMbqTkt64pN3PLxtVVqsrptRVl6nvX7Hupibwlr2n5y1verPjPQSRhR/6KNeQftH6odT +L2tAHMdsIrdPwjUn/x4tXZfse6oIPFevacSQbmyWcDsfLcL/wC1f514941v/wC3/HOuXiuuLvUJ pEZzhQGkOMnsACKHsFapzYKnHz/K56hpXxb8A6d8MbfQrjwo+qavHaNG09xaQqhlIJ3eZuL8E8HA OB2qp+zF4Q1bUPiPp2uxWcg0mwE3nXbgqhLROgVT/E2WGQOg69s7vxV8DfCfRvBdxc6DrNs2tRhf IjsdQFyZmyAQy7mwMZOeMe/Q0f2TNf1C38dXOkxzSNptzavNLAclFdSuHA7HnGe+R7UdS4qSxNOF Vp22t+v3H1zRRRVn04V86ftV635l/oWkq3EaPdOB6n5V/rX0XXx18edZGs/FDVdpBjtAlqMeqrk/ qxH4VMtjmxDtCx59nFfZvwT0f+xfhlocRTZJNEbhwfVyW/kRXx5pWnPrGqWdhGCZLqZIFx6swH9a +9rO1SxtILeIYjhRY1HoAMCpijDDK7bJq5n4la3/AMI74D1u/wA7XjtnVOf4mG0fqa6avG/2odYa y8DWthG37y+ulG0dSqgt/PFW9jsqS5YNlz9mrQ/7L+HS3bLiS/uHmye6g7R/6Cfzr1isXwXo40Dw lo+nBSv2e1jQg+u0Z/XNbVC0Q4R5YpFTV75dL0q8vGIC28Lykn/ZUn+leT/szae8nhXVdYnUGXUr 933EckL/APZFq6H49a3/AGJ8MdVKttkugtqnrlzg/pmuM+HXxs8F+DvBWk6RJc3Qnt4QJdtqxHmE 5bn6k0m9TKUoqorvZHuflr/dH5UoGBXl3/DSXgn/AJ+bz/wEemv+0r4KQZE9659BaNTujT2sO56p QTivE9S/an0GBGFjpV/dv2Mm2Jf1JP6V5l41/aB8SeLbZ7S38vRrJxhktWJkcehc8/kBSckZyrwj tqdL+0b8TYdZmXwxpsolt7aQSXkyH5WkHSMeuOp98eleSeENHbX/ABXpGnAZ+03UaEf7O7J/QGsg DFep/s36J/anxHS5Zcx2Fu8xPoxwq/zP5VG7OC7q1Fc+sY0EUaoowqgAD0FOoorU9cxvGWgyeKPC mraPFcC0e/tntvOZN4UONp4yM8E968j+Gf7M7+AfGlhr02ux6gtp5hEAtSmSyMgOd56bs9K91opW MJ0KdSanJarY8B8efswXfjbxfqmuN4kitvtsu8Q/Yy2xQAAM7+eAK7H4qfB6X4h+GNE0W21SPTLf TSDloDJv2psXGGGMDP516bRRYzWFpLmVvi33POPgv8If+FTWOpxPqCalNfSIxlSHy8KoIC/eOeWY /jXnPj/9lS71/wAVX+qaNq9tb217K9w8F2rbo3Y5YAqDkZJI6Y6c9a+jaKLBLCUZ01Ta0Wx5l4H+ Cllonwvn8I620WoJdyvPcSQAqA5xtKk85XauD7dK8o1L9j7VYryT+zPENo9schTcxujgEYwduQeC QT39K+pKKLIU8HRqJRlHbY8a+Ff7NumeAtTh1fU7v+2dUh+aEeXshgb+8ASSzDsT09MgEQ/Fj9nm 6+Jvi59ZGvRWMfkpAkBtS5ULnvvHUknpXtdFFkN4Si6fsuXQwPAXhVfBHg/S9DWYXH2KLYZgpUOx JJOMnGST3rw3xx+yZNqniC6vdA1W2tbO5dpfst2jZiYnJClQcrnOOBjpz1r6RootcqphqVWKhNaL Y+b7n9j5JNLsY4vEQS+Tebmd7Ysr5ChFVd4wFCnrknJ6DAHqXwc+F7fCvw7eaZLfpqRuLo3HmrCY 8Aoq7cbj/dJz7131FFrE08LRpT54Rsz5z8cfskpqWsTXnhvU4NPtZmLGyuUbbFnsjLnj0BHHrW18 K/2ZLTwZrMOsa3fR6te25D28EUZWGJx/GSeWI7cADrycY9yoosiVgqEZ+0UdTx742/ARvifqVpqu n6hHY6jFELeRLhSY5EDEg5HII3Hsc8dMVgeBf2atR8M6R4mt7rWLP7Vq1l9himhiZxEjMC5OSvXA GPb8K+gKKLFSwlGVT2jWp4b8MP2am+H3jOz16fXE1D7KsgSFbYx/MyFM53nsx7V6R8TvAqfEbwbe aG1wLR5mjeO4Kb/LZXDZxkZyAR1711VFFi4YenTg6cVozxn4Sfs6xfDbxM2s3WqR6tMkLRwKLfy/ KZuC+dx525H/AAI16B8Qvh9pfxI8PPpWpqygN5kM8f34ZACAw/MgjuK6aiiw4UKdOHs4rQ+V5/2P tbjuJFt/ENi9u2BvkjdGZcg8qMjsDjPUV6x8JfgLpPwxma/edtV1pk2fapECrCD1Ea84J6Ekk49A SD6hRRZIxp4OhSlzRjqFeMfF39n25+KPitNYGux2CJbJbLC1qZCApZuu8d2PavZ6KbVzoq0oVo8k 1dHK/DHwOPh14LsdC+0i8e3MjPcBNnmFnZs4ycYBA69q6qiiguMVCKjHZHjnxc/Z0sfiJqbaxp14 NK1aQATF03xT4AAJAIKtgYyM5x071wGlfsfanJdxDVPENslogwRaxs74ySQN2AOSeeep4r6iopWR xzwVCpLnlHUxPCHg7S/A+gQaPpNv5NpECSW5eVj1dz3Y/wCAGAAK8R8cfslQ6jqst54a1OLToZW3 GxuUJSMk/wADLyB6Ajj19PomiixtUw9KrFQktFsfOfgz9keKz1JLrxNqqX8KNu+x2asqyHP8TnnH qAM+9P8A2vb+Kw8M+GdGhRIo3uHmSJBhUWJAgAA4AxJgV9E1y3jL4Y+GviBPbS69ppv5LZWSI/aJ Y9oJBPCMB2HWi2mhzVMJGNGVKirNnyv8K/gTL8UfBt9qlpqI0++t702yCZd0Ui+WpYHHIPzjnkHk Y716x8Lf2YIfCOuxaxr19Dqk9swe2tYEIjVwch2J5JHUDAwRnJr2Dwp4P0jwPpX9m6JZiysvMaXy vMeT5jjJyxJ7DvWzSSJo4ClTUXJXkvzPFPiv+zxdfE3xdJrP9vx2MZhSFIGtTIVCg9946kk9O9eh eFPANpoHw+tfCl3s1C0jtmt5iU2rKGJLHGTjJY966minY640KcJuolq9z5l1/wDZBul1RptB16GO 0L7447xGEkXOQNy53Y9cCt74dfsqWHh3UoNR8Q3yavJAweOyhj2wbh0LE8uM9sAcc5HFe+UUWRjH A4eMuZRCs/X9CsvE2jXmlajCJ7K7jMUsecZB7g9iDyD2IrQopna0mrM+X9Z/Y8vlvW/snxBbvaE5 UXsTLIo9CVyD9cD6VreCf2R4NP1KK78SaqmoQxHd9htIyqSHtuc849QAPrX0VRSsjgWAw8Zc3Ked fGP4UTfFLR9N0631KPSoLOYykG3Mm75dqgAMMAAmq/wr+D0vwz8M63pyapHeXeoklbkQFBH8m1cr uJOCSeo616bRTsdPsKftPa294+ffBP7Kz+FfFmlaxP4givY7GdbjyBZldxXled5xg4PTtXmH7UWr DUvi1dwg5+w2sNtn/gPmY/8AIlfaNcHr3wN8E+J9XudU1PRTdX1y2+WY3c67jgDorgDgDoKlrscN fBJ0fZULLW7vf/gnhOmfss33iTwvoeraZrENv9vsorma2vFbCuy5BVlHIw3QjI55OePZfg58ELH4 VwzXUk66lrVwux7vZtWNODsQZPGQMnvgcCvR7Kzh06zgtbdBHbwRrFGgJO1VGAOfYVNTSsdFLB0a UlNLU+dJv2Tbi88Rvql14limWW7NzLELMjcC+5lzv78jNek/Gj4UL8VtAtraO8FjfWchlgldSyNk YKsB0B457Y6GvQqKLFxwtGMZRS0lufMuhfsfzrHeHV9bgZzEy2yWsblVkI4dySpIHPyjrxk4yD0v w4/Z2/4Vf4nTxLc6ymprZQSssCWmxslCCQS55wWH417rRRZGcMFQg1KMdV6nwS7WfxW+I19dXF1p vhCDUJJLhpLmQ+SjYycseNzHkk7Rkn2FXPHPwotfBulyXkXjHQNXZdhS0tLndcSKxxuCDPA55zjA P0r6a8Q/s3eBvEF691/Z8unSudziwmMaMf8AdOVH4AVQtf2V/AtvOJJIr+5QdYpbohT/AN8gH9e9 TY8t5fUd+ZJt9btfgeA+GfHV/ovwZ8RaXe2TanpN9dw2tn9pY+XBJtd5CuDnKlYWC8DJz6g0vAfw qsvG2kG6fxjoukXm91Fhey7ZcADDYJHB9Rn8+B9kXXw98N3vhiPw9No9q2jR/ctAuFQ8/MCOQ3J+ YHPJ55rz+b9lTwNLKzKuoxKeiJdcL9MqT+tOxpLAVPdvaSStrdHyr4m0P/hC9eihsNesdWdESaO/ 0a4LojZOAHGPmGM8eor7Q1TwLF8UfhnpFh4njki1J7OCeSVQFkgufLG4gdOpYEdKqeE/2ffBfhDU Ib620+S8vYW3RTXspk2NnIIXhcjjBxkYr0ehKx04XBuip8+0um6Plef9j7W47iRbfxDYvbtgb5I3 RmXIPKjI7A4z1FesfCX4C6T8MZmv3nbVdaZNn2qRAqwg9RGvOCehJJOPQEg+oUU7JHRTwdClLmjH U8Z+M37PUfxI1dNZ0y+j07UygjnWZC0cwHCtkchgOOhyAOmOeOtv2PpX0YJc+IY01PzgQ8cDPEkY DZUAsCSSQc8Yx05r6XoosgngqFSTnKOrPMvgt8Gf+FSrqxk1JNTlvzEN6weXsVN3H3j1L/oK9E1K G4uNOuorOZba7eJlimddwjcggMRkZwecVZopnTTpxpQUIKyPDfhv+zQPBXjO21/UNbXV2tt7pEbc qTKRgOSWOcZJ+uD2r0z4keDf+FgeCtS0D7QLQ3YjxOVLBCsiuDgEZ5X1rpqKVjOGHp04OnFaM8P+ GX7Ol78OPEratH4jjuS1tLb+WtqU+8ODneehAOPauSH7G1yBgeKoQB2+wn/45X07RRZGLwNBxUXH Reb6nzF/wxvc/wDQ1Rf+AJ/+OV678J/g1pXwqtZzbzPqGpXICzXsqBSVHO1Vydq55xk59eBXoFFF kiqWEoUZc0I6hRRRTOwhvLpLGznuZTtjhjaRiewAya+CdV1B9X1S8v5CTJdTPM2fVmJ/rX2L8aNZ Gh/DPXJs4eWH7Onuznb/ACJr4wAwMVEjz8S7tI9A+A+kjVvihpRYAx2oe6Yk8DauB+rCvsPzU/vr +dfJfwg+FCeNrO/1fUNUl0jSrQlDLA4RmIGWJY8BQOten6f+z14d1ayiu7LxRq93ayjMc8F4ro4z jIIGDzQtDSipxhzKOh7L5qf31/OvBPi848W/Gnwj4fVg8FuVmlGeOW3HP4J+tWbT4LeDL/UJrC28 b39xew7jJbRalG0ibeGyoGRjv6VTm+D3w9gihvpfHMsaTFliun1GEbyvDANjnGRnnihu50To15+7 yM9+EqAffX86PNT++v514Uvwb8EtZRXY8dXptZZRDHONTjKPIeiA9C3t1q5L8AfDMGpQ6fJ4s1VL +ZDJHatfIJHUdSFxkgetO5TjWW8DK/ar1vNvoOlIwId3uXwf7o2j/wBCNfPVfTOq/s5eFbC2a61P xFqMECcGe8uYwq/8CZeKztI+A/w/19ZW0zxXLqAhG6Q213BJsHqcDge9Q73OSeHrVL1FHQ+d6K+g rL4J/DjUtQFjaeMjc3jHaLeG+gZyfQADJNJF8FfhvPfrZR+MjJeM5jFut9AZC393bjOeOlBP1LEf ys+fqK9/j+DXw0mufs6eNlactt8oX9vuznpjHWue+LvwNtvh/oSaxp2oy3NqJVikhuQNwLcAqQBn 6YosZ1MNVpK842PIa+jP2VNE8vTNc1ZhzNMlsh9lG4/qw/KvnMnAyegr7K+B+if2F8MdFjZdsk8Z uXHu53fyIpx3DDxvO53lFFFaHphRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB4Z+1 TrfkaBpGlKx3XNwZnXP8KDj9TXzZX09+0V8OdV8XW+nappMLXktirxy2qffZGIO5fUgjpXz43gfx GpIOgamCO32R/wDCs5bnmV1Jzbsetah4W1/Uv2PNd03wla/b/EGq2U4hgidVZi77SMsQM7QeCa5H wp4Z+IOrJ8JPDlp4K13wf4X8FW5vNUe6u4o/t8scJEduixSEuGkO4hhtqj4fn+InhS3aDSbfW7K3 c7jClq5TPrgqcfhWt/wmPxZ/v65/4BH/AOJrGUFJ8zv/AE7n0OCzqWDw31ZUk9W7u903Hl7paLa6 0bPLtM+AvxL+HFl4a+Iug+DLq+8c6o+sxeINNjmiWXZdMzRM7Ftp2kA4BPUVt+FP2YvHD618MdMT w/o8GneE/DBaWbxNYi7tJdQuXLTp5SuMumF+bpyeuK7b/hMfiz/e1z/wCP8A8RQfGPxZ/v65/wCA R/8AiayWHgu/9W/yR7U+McXNP92r662d7PmstXa0VKSXk/JHD67+zD4j+Ft/4Ht7Pw5P47tR4pm8 V60NCt4rS2hkVCsEMMUknygFuOTwleha4vjrTP2lpPiLJ8NNb1nTz4XhsdMhs57YvazMWklSQNKA G3EKSOPlHNVf+Ex+LP8Af1z/AMAj/wDEUf8ACY/Fn+9rn/gEf/iapUYx+Fv/AIbQ5p8UVq2tekpP llFt3V1J3ezSXbRLTQ4O5+CnxTt7b4Z3Pi7w3qHjXSxrl9rniDRo71Ll4S5P2WIrJIFZUByVGQDw Ku+JvhJ8TvEXgn4t6jongLTvDt9qqRafpFrbWsFlqM9ruBlMjRyFDhcqoOCe9df/AMJj8Wf72uf+ AR/+Io/4TH4s/wB7XP8AwCP/AMTU/V42td/0rf15m3+ttfmjL2Mbp9nb4+e1ua3l35Ul5mdpnw78 Q3nj7wlPoXwhs/DPhrw5pjyvJqmm2ovPtKx4RLeSKQsWZsZZhjj3rF/Z1+F/jPwToWoXmt+BNTg8 TP8A2jqe2awsHU3Mm7y1S5yZd2CuOcdegrq/+Ex+LP8Af1z/AMAj/wDEUf8ACY/Fn+/rn/gEf/ia tUop3u/6t/kYy4oqypSoukrO3e+jk92+vM7/ACPKNM/Z/wDFXiT4FaP8OpfhHc6b4vvb9bjU/Gmo LZKbcG486V1kVjITtJRQB6V9HftL366T4W8N+Hkk3tuEj5PJWNAoJ/E/pXEf8Jj8Wf7+uf8AgEf/ AImua1vR/GvibUDeappusX12wC+ZNbPkAdAOMAVVOmqasvJfcedm2eVs2jyzhyq8paX3la+7emiS Sskc3Y2T6lfW1nGCXuJVhAHqxA/rX3tplkum6ba2iDCQRLGAPYAV89fBX4HanHrtrr3iC2Njb2p8 y3tJMeZI/YsOwHX1Jr6ProirHjYeDim2FFFFUdYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFAH//2Q== ------=_NextPart_000_0000_01C02FAF.8916D0D0 Content-Type: image/gif; name="Blank Bkgrd.gif" Content-Transfer-Encoding: base64 Content-ID: <565580313@06102000-2cc1> Content-Transfer-Encoding: base64 R0lGODlhLQAtAID/AP////f39ywAAAAALQAtAEACcAxup8vtvxKQsFon6d02898pGkgiYoCm6sq2 7iqWcmzOsmeXeA7uPJd5CYdD2g9oPF58ygqz+XhCG9JpJGmlYrPXGlfr/Yo/VW45e7amp2tou/lW xo/zX513z+Vt+1n/tiX2pxP4NUhy2FM4xtjIUQAAOw== ------=_NextPart_000_0000_01C02FAF.8916D0D0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 10:54: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 KAA05682 for ; Fri, 6 Oct 2000 10:54:49 -0400 (EDT) Received: from standards (47.234.32.16:2817) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9EA8C@standards.nortelnetworks.com>; Fri, 6 Oct 2000 10:38:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30760 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 10:38:26 -0400 Received: from ms.samsung.com (211.45.29.136:54152) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9EA7E@standards.nortelnetworks.com>; Fri, 6 Oct 2000 10:28:25 -0400 Received: from keg ([203.241.151.111]) by ms.samsung.com (Netscape Messaging Server 4.15) with SMTP id G20JIC00.M5L for ; Fri, 6 Oct 2000 23:42:12 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Message-ID: <041901c02fa1$a5f65bc0$88b2d5a5@keg.telecom.samsung.co.kr> Date: Fri, 6 Oct 2000 23:28:08 +0900 Reply-To: Woo-June Kim Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Woo-June Kim Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id KAA05682 Fredrik, The mobile node itself just generates a random number to use as the challenge. The response can only be correctly calculated by the mobile if it knows the correct key and algorithm. The AAA is simply using this fact to check the mobile's identity in a round-about manner. The challenge value itself is not something that must be generated in some special manner. cheers >BlankHi > >I have a question concerning how Challenge / Response is supposed to work >when a mobile node registers using a co-located foreign agent. > >Since the mobile node does not receive an advertisement with a challenge >from a FA it cannot calculate a response to be used in a MN-AAA >Authentication extension, i.e., the Home Agent cannot use a Radius server to >authenticate the MN. > >Have there been any thoughts in this area, or perhaps a solution in an >earlier thread that I've missed? Thankful for any pointers. > >Regards >/Fredrik >----------------------------------------- >Fredrik Johansson > >W: +46 (0)8 725 5916 >M: +46 (0)70 786 5035 >mailto:Fredrik.Johansson@ipunplugged.com >http://www.ipunplugged.com > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 11: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 LAA05926 for ; Fri, 6 Oct 2000 11:05:42 -0400 (EDT) Received: from standards (47.234.32.16:2817) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9EAF0@standards.nortelnetworks.com>; Fri, 6 Oct 2000 10:49:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30790 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 10:49:15 -0400 Received: from nausicaa.coritel.it (193.205.242.5:33213) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9EA98@standards.nortelnetworks.com>; Fri, 6 Oct 2000 10:39:14 -0400 Received: from fermi (fermi.coritel.it [193.205.242.3]) by nausicaa.coritel.it (8.9.3/8.9.3) with SMTP id PAA03333 for ; Fri, 6 Oct 2000 15:37:45 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C02FB7.B7321FD0" 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.2314.1300 Importance: Normal Message-ID: Date: Fri, 6 Oct 2000 17:06:06 +0200 Reply-To: Tonino Villani Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Tonino Villani Subject: [MOBILE-IP] unsubscribe To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A5089EB251@eaubrnt018.epa.ericsson.se> This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C02FB7.B7321FD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit draft for WG consensusunsubscribe ------=_NextPart_000_0008_01C02FB7.B7321FD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft for WG consensus
unsubscribe
------=_NextPart_000_0008_01C02FB7.B7321FD0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 11:47: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 LAA06847 for ; Fri, 6 Oct 2000 11:47:58 -0400 (EDT) Received: from standards (47.234.32.16:2373) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9EBC0@standards.nortelnetworks.com>; Fri, 6 Oct 2000 11:31:31 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31170 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 11:31:31 -0400 Received: from hotmail.com (f7.law3.hotmail.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9EBBF@standards.nortelnetworks.com>; Fri, 6 Oct 2000 11:31:30 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 6 Oct 2000 08:46:04 -0700 Received: from 192.76.68.115 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 06 Oct 2000 15:46:04 GMT X-Originating-IP: [192.76.68.115] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 06 Oct 2000 15:46:04.0365 (UTC) FILETIME=[88E037D0:01C02FAC] Message-ID: Date: Fri, 6 Oct 2000 15:46:04 GMT Reply-To: amarnath gudlavalleti Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: amarnath gudlavalleti Subject: [MOBILE-IP] unsubscribe To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM _________________________________________________________________________ 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. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 11:55: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 LAA06994 for ; Fri, 6 Oct 2000 11:55:24 -0400 (EDT) Received: from standards (47.234.32.16:2373) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9EBF6@standards.nortelnetworks.com>; Fri, 6 Oct 2000 11:37:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31160 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 11:37:04 -0400 Received: from ogma.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9EBB8@standards.nortelnetworks.com>; Fri, 6 Oct 2000 11:27:03 -0400 Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id 0BD22F7; Fri, 6 Oct 2000 17:41:37 +0200 (MET DST) Received: from gfeige-8kcdt.cisco.com (gfeige-isdn-home2.cisco.com [10.49.90.187]) by europe.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA06191; Fri, 6 Oct 2000 17:41:34 +0200 (MET DST) X-Sender: gfeige@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4.3.2.7.2.20001006173907.00c518b0@europe.cisco.com> Date: Fri, 6 Oct 2000 17:41:31 +0100 Reply-To: Gaetan Feige Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gaetan Feige Subject: Re: [MOBILE-IP] MIP implementation !!! X-To: Vipul Gupta To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200010042150.OAA21514@nasnfs.eng.sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA06994 Hello all, Following the question on Mobile-IP implementations on Linux I would like to know if there are some starts of implementation for Windows 2000 ? I heard the Singapore stack works on windows 98. Thank you very much Gaétan At 14:50 04/10/2000 -0700, Vipul Gupta wrote: > The folks behind the SUNY Binghamton implementation have moved > on and that implementation is no longer maintained actively. > If you are interested in something that works on Linux 2.2, you can try > the distribution from Sun Labs at: > > http://playground.sun.com/~vgupta/sunlabs-mobileip-new.tar.gz > > regards, > > vipul > > > p.s. If you are specifically looking for the Binghamton implementation, > a copy can be found at > > http://playground.sun.com/pub/mobile-ip/Linux/Linux-MobileIPv101.tar.gz > > be warned, though, the last Linux kernel it was tested on is > 1.3.58 (or thereabouts) and will not work on 2.2. > > Other Linux implementations are available from: > > o National University of Singapore (http://mip.ee.nus.sg/) > > o Stanford University as part of the Mosquitonet project > (http://mosquitonet.stanford.edu/) > > > >> Good morning folks ! >> Can someone please tell me whats going on with >> the Binghamton UNIs URL for the Linux implementation >> on Mobile IP? Its been for ages that Im trying to download >> the files but it seems that the URL doesn't work anymore. >> Does anyone know if they have any updated versions of the >> implementation which runs on 2.2.x Kernells? >> >> Regards, >> Christos >> >> -- >> Christos Chrisanthakopoulos >> >> INTRACOM S.A. >> Development Programmes Department >> Panepistimiou 254 >> 26443 Patras >> GREECE >> >> Tel: (+30 61) 465153 (direct) >> E-mail: xchr@intranet.gr >> URL: www.intracom.gr ************************************************************* Gaetan Feige Technical Consultant 11, rue Camille Desmoulins TEL: +33 (0)1 58 04 68 36 92782 Issy Les Moulineaux FAX: +33 (0)1 58 04 61 00 CEDEX 9 - France GSM: +33 (0)6 89 10 82 89 ************************************************************* From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 12:31: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 MAA07799 for ; Fri, 6 Oct 2000 12:31:23 -0400 (EDT) Received: from standards (47.234.32.16:2373) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9ECBA@standards.nortelnetworks.com>; Fri, 6 Oct 2000 12:14:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31493 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 12:14:52 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9ECB9@standards.nortelnetworks.com>; Fri, 6 Oct 2000 12:14:51 -0400 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 JAA03835; Fri, 6 Oct 2000 09:29:24 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e96GTKh19731; Fri, 6 Oct 2000 09:29:20 -0700 X-Virus-Scanned: Fri, 6 Oct 2000 09:29:20 -0700 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) smtpdiI9PYh; Fri, 06 Oct 2000 09:29:04 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <200010041930.e94JUAA00260@locked.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39DDFDD2.214BF722@iprg.nokia.com> Date: Fri, 6 Oct 2000 09:29:06 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySupport in IPv6"draft] X-To: Mohan Parthasarathy To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Mohan, Thanks for your note. >> 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 > > Why do you say "might" here ? It is a bit confusing. The care-of address is only in the IPv6 header when the Home Address destination option is present. It is not required for all packets to contain the Home Address destination option, for instance if the mobile node is at home. In fact, I wish it were not required even when the mobile node is away from home. In the future, if my fantasy comes true and ingress filtering is abolished, there will no longer be such a need for this restriction. My reading of the current specification would be that the mobile node SHOULD include a Home Address option in every outgoing packet when it is away from its home domain, and thus possibly subject to ingress filtering. Perhaps it would be good to make this explicit in the draft -- or maybe it is already in there and I have just not seen it lately. ------------------ >> Of course, this also means that the node receiving a packet >> with AH will have to follow the same algorithm, which >> basically just means not moving data fields at all. >> The only complication comes when it is necessary to look up >> the appropriate security association for processing either >> AH or ESP. That lookup, typically indexed by the >> Source IP address of the IPv6 header, would instead have >> to be indexed by the home address in the Home Address >> destination option. Since that destination option would >> occur in the packet _before_ the security header, >> processing is still very simple. > > If you do it this way then other sections need change because > currently the draft in section 5.4 talks about Home address > option processing on receipt of a packet : > > ... on receipt of a packet with Home Address option, > the receiving node replaces the Source Address in the IPv6 header > with the Home Address in the Home Address option. Right. If this change were to be made, the specification would require a very careful re-reading. All 100 pages of it. I'd like to find a solution agreeable to everyone, make it correct and clear (to avoid the current problems of apparent ambiguity), make it simple and amenable to very natural processing, and get it done. The important point here is to find the simple and natural solution. I hope you (and others) will be able to give the following discussion some very careful consideration to help me make sure I understand the problem before tackling the final specification. > I think there are other places. This tells me that the first > thing i do is swap the addresses (or pointers ) and then > do the AH computation. That is sort-of what draft 12 says (apparently subject to multiple interpretations), isn't it? It wasn't my proposal, which was to leave the addresses in place (both on the transmit side and the receive side). > If this is correct and working > out the transmit side based on this, you would need > the following: > > 1) Insert a home address option with the CoA in it. > 2) Do the IPsec processing (this includes SPD lookups which > needs the right source address and hence gels in easily) > 3) swap the addresses in the source field of the IPv6 header with > the one in Home Address option after IPsec processing. I propose, on the transmit side, the following: 1) Put in AH, but leave the authentication field blank. 2) Put in the other fields as needed. 3) Put in the Home Address option with the Home Address 4) Put in the other fields as needed. 5) Put in the IPv6 header, with the Care-of Address in the ip6_src field 6) Do the IPsec computation. It seems to me that all the trouble comes on the receive side, in deciding what address to pass to the higher level protocols. If the Home Address option is present, then the receiver is suddenly required to either: - change the fields of the received IPv6 header, or - change the way that data is structured to build the pseudo-header for the higher-level protocols. It seems to me that the latter is preferable, given all of the other considerations. If my proposal finds acceptance, then the programming steps for removing all of the IPv6-level headers and passing the results to, say, TCP, would require that the mobile node's actual home address be stored somewhere else than the received packet header. Another alternative would be to do some sort of header field swapping AFTER the AH processing occurs, but that seems even less natural than doing some sort of swap during the processing of the Home Address option. > We just have to describe the bits that pass through AH computation. > Swapping is just a word to describe the contents of the home > address option and the ipv6 source address field. This is no > way modifying the contents of the packet. ... well, it seems like your statement requires a special meaning for the word "contents". Maybe you mean "payload"... > Is the above ambiguous still ? Either way is fine by me > as long as it is consistent. With your suggestion, you > have to make sure that all sections that discusses > about Home Address option processing is clear i.e > AH before swap or swap before AH ? What do you think about the "not at all swap" proposal? Or have I missed something else important here? Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 13:05: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 NAA08612 for ; Fri, 6 Oct 2000 13:05:03 -0400 (EDT) Received: from standards (47.234.32.16:1487) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9ED1B@standards.nortelnetworks.com>; Fri, 6 Oct 2000 12:48:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31618 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 12:48:35 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9ED1A@standards.nortelnetworks.com>; Fri, 6 Oct 2000 12:48:35 -0400 Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id e96H38t23547 for ; Fri, 6 Oct 2000 19:03:08 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Fri Oct 06 18:56:51 2000 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id <4MC35NYX>; Fri, 6 Oct 2000 19:01:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <5F05C89FB2F8D211B6430008C791912703EA81B2@esealnt190> Date: Fri, 6 Oct 2000 19:02:49 +0200 Reply-To: "Karim El-Malki (ERA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Karim El-Malki (ERA)" Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac hes To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > 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 Fri Oct 6 13:36: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 NAA09195 for ; Fri, 6 Oct 2000 13:36:33 -0400 (EDT) Received: from standards (47.234.32.16:1487) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9ED84@standards.nortelnetworks.com>; Fri, 6 Oct 2000 13:20:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31729 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 13:20:02 -0400 Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9ED70@standards.nortelnetworks.com>; Fri, 6 Oct 2000 13:10:01 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id KAA02024 for ; Fri, 6 Oct 2000 10:24:35 -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 KAA09212 for ; Fri, 6 Oct 2000 10:24:35 -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.2650.21) id TT7QDY2S; Fri, 6 Oct 2000 12:23:51 -0500 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 Message-ID: Date: Fri, 6 Oct 2000 12:32:08 -0500 Reply-To: Ajoy Singh Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ajoy Singh Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac hes To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <5F05C89FB2F8D211B6430008C791912703EA81B2@esealnt190> Content-Transfer-Encoding: 7bit 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. >> Can you please be more specific and provide some example in context of any present or future wireless network ? Please provide some messaging information and mention how L3 registartion will be done before L2 handoff is complete. To me it looks like that you are assuming too many things which is not be doable in a real system. -----Original Message----- From: IP Routing for Wireless/Mobile Hosts (mobile-ip) [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Karim El-Malki (ERA) Sent: Friday, October 06, 2000 12:03 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM 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 Fri Oct 6 14:05: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 OAA09651 for ; Fri, 6 Oct 2000 14:05:47 -0400 (EDT) Received: from standards (47.234.32.16:1487) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9EDE6@standards.nortelnetworks.com>; Fri, 6 Oct 2000 13:49:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31886 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 13:49:16 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9EDE5@standards.nortelnetworks.com>; Fri, 6 Oct 2000 13:49:15 -0400 Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id e96I3nt01567 for ; Fri, 6 Oct 2000 20:03:49 +0200 (MEST) Received: FROM esealnt172.ericsson.se BY esealnt461 ; Fri Oct 06 19:57:30 2000 +0200 Received: by esealnt172 with Internet Mail Service (5.5.2651.58) id <4GAKX79D>; Fri, 6 Oct 2000 20:03:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <5F05C89FB2F8D211B6430008C791912703EA81B4@esealnt190> Date: Fri, 6 Oct 2000 20:03:46 +0200 Reply-To: "Karim El-Malki (ERA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Karim El-Malki (ERA)" Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac hes To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > 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. > >> Can you please be more specific and provide some example > in context of > any present or future wireless network ? Please provide some messaging > information and mention > how L3 registartion will be done before L2 handoff is > complete. To me it > looks like > that you are assuming too many things which is not be doable in a real > system. The point is that any further specification of the above interaction of L2/L3 would bring in L2 issues specific to a certain wireless/cellular system which is what we decided was out of scope. I think that the above explanation is quite clear. What is it that we are assuming that is so unrealistic? I definitely think our assumptions are no less realistic than those in the Proactive draft, if that is what you meant. /Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 14:13: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 OAA09760 for ; Fri, 6 Oct 2000 14:13:30 -0400 (EDT) Received: from standards (47.234.32.16:1487) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9EE2D@standards.nortelnetworks.com>; Fri, 6 Oct 2000 13:57:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31979 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 13:57:04 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9EE2C@standards.nortelnetworks.com>; Fri, 6 Oct 2000 13:57:03 -0400 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA14245 for ; Fri, 6 Oct 2000 12:11:27 -0600 (MDT) 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 LAA22716; Fri, 6 Oct 2000 11:11:26 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id LAA20073; Fri, 6 Oct 2000 11:11:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Fri, 6 Oct 2000 11:09:15 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac hes X-To: "Karim El-Malki (ERA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <5F05C89FB2F8D211B6430008C791912703EA81B4@esealnt190> > > The point is that any further specification of the above interaction > of L2/L3 would bring in L2 issues specific to a certain wireless/cellular > system which is what we decided was out of scope. I think that the > above explanation is quite clear. We need to be careful in setting the scope. In my opinion, what is out of scope is a solution that cannot work with known wireless technologies. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 14:13: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 OAA09769 for ; Fri, 6 Oct 2000 14:13:31 -0400 (EDT) Received: from standards (47.234.32.16:1487) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9EE40@standards.nortelnetworks.com>; Fri, 6 Oct 2000 13:58:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32003 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 13:58:41 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9EE3F@standards.nortelnetworks.com>; Fri, 6 Oct 2000 13:58:40 -0400 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 LAA14255; Fri, 6 Oct 2000 11:13:14 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e96IDBZ08389; Fri, 6 Oct 2000 11:13:11 -0700 X-Virus-Scanned: Fri, 6 Oct 2000 11:13:11 -0700 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) smtpd4uOyg7; Fri, 06 Oct 2000 11:13:03 PDT X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39DE15DD.AF47BB67@iprg.nokia.com> Date: Fri, 6 Oct 2000 11:11:41 -0700 Reply-To: Charlie Perkins Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Charlie Perkins Organization: Nokia Subject: Re: [MOBILE-IP] Are requirements required? X-To: Roberts Philip-qa3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Phil, I agree with what I think you are trying to say. And I don't have a problem with modifying Mobile IP to fit the needs, say, for seamless handover. I wanted to make it clear that (as best I understand it) Mobile IP was designed to allow interworking with other ways to get timely information about moving to a new point of attachment. I agree with you that the number of current proposals points out the need to do so. Roberts Philip-qa3445 wrote: > > I think I've digested all the wording here and I think I agree. Perhaps if > I'd said "Mobile IP as it's currently defined wil have trouble ... on a lot > of systems in which people seem to be interested in using it" you would have > been more sympathetic? No doubt one could send 1000 advertisements a > second in some systems, but probably not in most cellular systems. And no > doubt one might be able to implement a link layer that could be engineered > to automatically generate an advertisement at a mobile without sending it > over the air. Might we also agree that the number of proposals being > generated in the working group to improve handoff performance gives the > impression that maybe some things could be done to modify MIP to make it a > little better for this in the context of some real systems? Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 15:05: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 PAA10947 for ; Fri, 6 Oct 2000 15:05:27 -0400 (EDT) Received: from standards (47.234.32.16:1487) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9EF61@standards.nortelnetworks.com>; Fri, 6 Oct 2000 14:46:31 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32339 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 14:46:31 -0400 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9EF3B@standards.nortelnetworks.com>; Fri, 6 Oct 2000 14:36:31 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id LAA09485 for ; Fri, 6 Oct 2000 11:50:44 -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 LAA18918 for ; Fri, 6 Oct 2000 11:50:44 -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.2650.21) id TT7QD78C; Fri, 6 Oct 2000 13:50:00 -0500 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 Message-ID: Date: Fri, 6 Oct 2000 13:58:17 -0500 Reply-To: Ajoy Singh Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ajoy Singh Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff approach hes To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <5F05C89FB2F8D211B6430008C791912703EA81B4@esealnt190> Content-Transfer-Encoding: 7bit The point is that any further specification of the above interaction of L2/L3 would bring in L2 issues specific to a certain wireless/cellular system which is what we decided was out of scope. < I was not asking you to specify these detail in fast handoff. Does out of scope mean that any claim about link layer is possible ? I think that the above explanation is quite clear. What is it that we are assuming that is so unrealistic? You are trying to make sure that you will have enough time, after link layer handoff is detected, to do everything as specified in section 4 of fast handoff draft before mobile goes out of range. I definitely think our assumptions are no less realistic than those in the Proactive draft, if that is what you meant. In proactive draft, we are not making any claim to register with mobile node through the old access point before link layer handoff is complete. We are just talking about some link layer trigger, even fast handoff draft talks about that. In quick handoff draft(personal id submitted by Sebastian and me), we have specified how we can get link layer trigger without making lot of changes in current L2 technologies. The details are not included in proactive draft because of the scope of the mobile/IP protocol. -----Original Message----- From: IP Routing for Wireless/Mobile Hosts (mobile-ip) [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Karim El-Malki (ERA) Sent: Friday, October 06, 2000 1:04 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac hes > 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. > >> Can you please be more specific and provide some example > in context of > any present or future wireless network ? Please provide some messaging > information and mention > how L3 registartion will be done before L2 handoff is > complete. To me it > looks like > that you are assuming too many things which is not be doable in a real > system. The point is that any further specification of the above interaction of L2/L3 would bring in L2 issues specific to a certain wireless/cellular system which is what we decided was out of scope. I think that the above explanation is quite clear. What is it that we are assuming that is so unrealistic? I definitely think our assumptions are no less realistic than those in the Proactive draft, if that is what you meant. /Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 15:32: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 PAA11484 for ; Fri, 6 Oct 2000 15:32:16 -0400 (EDT) Received: from standards (47.234.32.16:1487) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F009@standards.nortelnetworks.com>; Fri, 6 Oct 2000 15:15:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32611 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 15:15:53 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F007@standards.nortelnetworks.com>; Fri, 6 Oct 2000 15:15:39 -0400 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA21794 for ; Fri, 6 Oct 2000 13:30:10 -0600 (MDT) 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 MAA12957 for ; Fri, 6 Oct 2000 12:29:41 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA22420 for ; Fri, 6 Oct 2000 12:29:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Fri, 6 Oct 2000 12:27:26 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: [MOBILE-IP] Comment on draft-ietf-mobileip-reg-tunnel-03.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" I have a comment on draft-ietf-mobileip-reg-tunnel-03.txt, section 4.1, which reads: 4.1. Regional Registration Flag The Agent Advertisement message MAY include a flag indicating whether the domain, to which the foreign agent generating the Agent Advertisement belongs, supports regional registrations. The flag is inserted in one of the reserved fields, after the flags defined in [9]. The flag is defined as follows: I Regional registration. This domain supports Regional Registration as specified in this document. When I implemented this feature, I ended up using a bit that was free according to [9] (RFC 2002). Unfortunately, as I am adding Reverse Tunneling support, I see that the bit I had randomly chosen (given the rather vague directives above) conflicts with Reverse Tunneling. Could the authors of the above I-D add some clearer directives to implementors? Thanks, PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 15:46: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 PAA11641 for ; Fri, 6 Oct 2000 15:46:36 -0400 (EDT) Received: from standards (47.234.32.16:1487) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F067@standards.nortelnetworks.com>; Fri, 6 Oct 2000 15:30:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32683 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 15:30:13 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F02D@standards.nortelnetworks.com>; Fri, 6 Oct 2000 15:19:02 -0400 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA23721; Fri, 6 Oct 2000 13:33:34 -0600 (MDT) 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 MAA00213; Fri, 6 Oct 2000 12:33:33 -0700 (PDT) Received: (from mohanp@localhost) by locked.eng.sun.com (8.10.1+Sun/8.10.1) id e96JWV304628; Fri, 6 Oct 2000 12:32:31 -0700 (PDT) X-Sun-Charset: US-ASCII Message-ID: <200010061932.e96JWV304628@locked.eng.sun.com> Date: Fri, 6 Oct 2000 12:32:31 -0700 Reply-To: Mohan Parthasarathy Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mohan Parthasarathy Subject: Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySupport in IPv6"draft] X-To: charliep@iprg.nokia.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > > Hello Mohan, > > Thanks for your note. > > >> 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 > > > > Why do you say "might" here ? It is a bit confusing. > > The care-of address is only in the IPv6 header when the > Home Address destination option is present. It is not required > for all packets to contain the Home Address destination option, > for instance if the mobile node is at home. > > In fact, I wish it were not required even when the mobile > node is away from home. In the future, if my fantasy comes > true and ingress filtering is abolished, there will no longer > be such a need for this restriction. > > My reading of the current specification would be that the > mobile node SHOULD include a Home Address option in every > outgoing packet when it is away from its home domain, and > thus possibly subject to ingress filtering. Perhaps it would > be good to make this explicit in the draft -- or maybe it > is already in there and I have just not seen it lately. > In section 7.4, - Every IPv6 mobile node MUST support sending packets containing a Home Address option; this option MUST be included in all packets sent while away from home, if the packet would otherwise have been sent with the mobile node's home address as the IP Source Address. It is a MUST and it is not very easy to figure out what it means by just reading it once :-) > ------------------ > > >> Of course, this also means that the node receiving a packet > >> with AH will have to follow the same algorithm, which > >> basically just means not moving data fields at all. > >> The only complication comes when it is necessary to look up > >> the appropriate security association for processing either > >> AH or ESP. That lookup, typically indexed by the > >> Source IP address of the IPv6 header, would instead have > >> to be indexed by the home address in the Home Address > >> destination option. Since that destination option would > >> occur in the packet _before_ the security header, > >> processing is still very simple. > > > > If you do it this way then other sections need change because > > currently the draft in section 5.4 talks about Home address > > option processing on receipt of a packet : > > > > ... on receipt of a packet with Home Address option, > > the receiving node replaces the Source Address in the IPv6 header > > with the Home Address in the Home Address option. > > Right. If this change were to be made, the specification would > require a very careful re-reading. All 100 pages of it. > I'd like to find a solution agreeable to everyone, make it > correct and clear (to avoid the current problems of apparent > ambiguity), make it simple and amenable to very natural > processing, and get it done. > > The important point here is to find the simple and natural > solution. I hope you (and others) will be able to give the > following discussion some very careful consideration to help > me make sure I understand the problem before tackling the > final specification. > > > I think there are other places. This tells me that the first > > thing i do is swap the addresses (or pointers ) and then > > do the AH computation. > > That is sort-of what draft 12 says (apparently subject to > multiple interpretations), isn't it? It wasn't my proposal, > which was to leave the addresses in place (both on the > transmit side and the receive side). > I should not have used the word swap above. There is ambiguity and i would like to interpret it as swap. > > If this is correct and working > > out the transmit side based on this, you would need > > the following: > > > > 1) Insert a home address option with the CoA in it. > > 2) Do the IPsec processing (this includes SPD lookups which > > needs the right source address and hence gels in easily) > > 3) swap the addresses in the source field of the IPv6 header with > > the one in Home Address option after IPsec processing. > > I propose, on the transmit side, the following: > 1) Put in AH, but leave the authentication field blank. > 2) Put in the other fields as needed. > 3) Put in the Home Address option with the Home Address > 4) Put in the other fields as needed. > 5) Put in the IPv6 header, with the Care-of Address in the > ip6_src field > 6) Do the IPsec computation. > At step (6), i have to look at my SPD/SADB for doing IPsec. Source address could be one of the IPsec selectors. In that case, the code needs to look for home address option and if present, do lookups with the Home Address, otherwise use the CoA. Is this natural ? > It seems to me that all the trouble comes on the receive side, > in deciding what address to pass to the higher level protocols. > We also need to know the Home address for verifying IPsec policy checks later. It might be easier if it is present in the IPv6 source address field as that's how the normal code would work without the option. > If the Home Address option is present, then the receiver is > suddenly required to either: > - change the fields of the received IPv6 header, or > - change the way that data is structured to build the > pseudo-header for the higher-level protocols. > > It seems to me that the latter is preferable, given all of the > other considerations. If my proposal finds acceptance, then > the programming steps for removing all of the IPv6-level headers > and passing the results to, say, TCP, would require that the > mobile node's actual home address be stored somewhere else > than the received packet header. > > Another alternative would be to do some sort of header field > swapping AFTER the AH processing occurs, but that seems even > less natural than doing some sort of swap during the processing > of the Home Address option. > Or change the transmit side processing as i suggested. > > We just have to describe the bits that pass through AH computation. > > Swapping is just a word to describe the contents of the home > > address option and the ipv6 source address field. This is no > > way modifying the contents of the packet. > > ... well, it seems like your statement requires a special > meaning for the word "contents". Maybe you mean "payload"... > Actually i meant the payload. > > Is the above ambiguous still ? Either way is fine by me > > as long as it is consistent. With your suggestion, you > > have to make sure that all sections that discusses > > about Home Address option processing is clear i.e > > AH before swap or swap before AH ? > > What do you think about the "not at all swap" proposal? > Or have I missed something else important here? > What we need is the actual bits passed through AH i.e what does the IPv6 header's source address, detination address and the home address option contain while doing the outbound and inbound AH computation. How you derive those should be left to the implementation. While explaining the home address option on inbound, the draft has to mention that if this option is present, it contains the home address and this will be needed for IPsec processing. Why should it talk about updating the source address field of the IPv6 header ? How you form the bits to do IPsec AH computation should be left to the implementation ? We can just describe the contents of the Ipv6 source address field and the Home address option. -mohan > Regards, > Charlie P. > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 16:32: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 QAA12366 for ; Fri, 6 Oct 2000 16:32:19 -0400 (EDT) Received: from standards (47.234.32.16:1487) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F0ED@standards.nortelnetworks.com>; Fri, 6 Oct 2000 16:15:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32887 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 16:15:54 -0400 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F0DA@standards.nortelnetworks.com>; Fri, 6 Oct 2000 16:05:28 -0400 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id NAA13507 for ; Fri, 6 Oct 2000 13:19:40 -0700 (MST)] Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id NAA22906 for ; Fri, 6 Oct 2000 13:19:40 -0700 (MST)] Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2651.58) id <429P8P7C>; Fri, 6 Oct 2000 15:18:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02FD2.A5999F80" Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A0498FB1E@il27exm02.cig.mot.com> Date: Fri, 6 Oct 2000 15:18:53 -0500 Reply-To: Nakhjiri Madjid-MNAKHJI1 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Nakhjiri Madjid-MNAKHJI1 Subject: Re: [MOBILE-IP] Are requirements required? X-To: "Hesham Soliman (EPA)" 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_01C02FD2.A5999F80 Content-Type: text/plain Hesham, Andrew, Could you please let me know where the paper co-authored by Andrew on the mobility management approaches can be found? Thank you, Madjid Nakhjiri -----Original Message----- From: Hesham Soliman (EPA) [mailto:Hesham.Soliman@ERICSSON.COM.AU] Sent: Tuesday, October 03, 2000 5:20 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Are requirements required? Hi Sandy, > The mobile IP working group is not taking fast handoff from its charter. > We've consolidated the charter to consider mobile IP based approaches only > and we hope to end up with two approaches to doing fast handoff based on > mobile IP - one for v4 and one for v6. The other working group that is > being proposed may investigate alternate approaches that are not based on > mobile IP. In my mind, fast-handoff = micro-mobility. In your definition, fast handoff = (some mechanism based on Mobile IP) whereas micro-mobility = (some mechanism not based in Mobile IP). Is this correct? If so, can you explain what are the necessary conditions for a mechanism to be classified as being "based on Mobile IP"? This is too vague. => I was guessing that's what was on your mind, may I ask why fast handoff = micromobility ? If we can achieve the performance targets that we're aiming for using MIP and some extensions wouldn't that be better and much less complex than inventing new protocols ? Let alon saving years of IETF work ? In the second session for MIP WG in Pittsburgh, Andrew Campbell mentioned that he was a co-author on a paper that did an evaluation / comparison of the various mobility management schemes. I've read that paper, and on the handoff issue, it was concluded that there were no significant differences between HMIP, CIP and HAWAII. Andrew also mentioned that in is presentation. I may also add that the simulations in that paper did not consider the Fast Handoffs draft (draft-elmalki- ...) which adds improvements to standard HMIP. So when I hear this direct association between micro mobility and fast handoffs, I get a bit confused. ------_=_NextPart_001_01C02FD2.A5999F80 Content-Type: text/html RE: [MOBILE-IP] Are requirements required?
Hesham, Andrew,
 
Could you please let me know where the paper co-authored by Andrew on the mobility management approaches can be found?
 
Thank you,
 
Madjid Nakhjiri
-----Original Message-----
From: Hesham Soliman (EPA) [mailto:Hesham.Soliman@ERICSSON.COM.AU]
Sent: Tuesday, October 03, 2000 5:20 PM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] Are requirements required?

Hi Sandy,


    > The mobile IP working group is not taking fast handoff from its charter.
    > We've consolidated the charter to consider mobile IP based approaches only
    > and we hope to end up with two approaches to doing fast handoff based on
    > mobile IP - one for v4 and one for v6.  The other working group that is
    > being proposed may investigate alternate approaches that are not based on
    > mobile IP.

    In my mind, fast-handoff = micro-mobility.  In your
    definition,  fast handoff = (some mechanism based on
    Mobile IP) whereas micro-mobility = (some mechanism
    not based in Mobile IP).  Is this correct? If so,
    can you explain what are the necessary conditions for
    a mechanism to be classified as being "based on
    Mobile IP"?  This is too vague.

    => I was guessing that's what was on your mind, may I ask why
    fast handoff = micromobility ?
    If we can achieve the performance targets that we're aiming for
    using MIP and some extensions wouldn't that be better and much less
    complex than inventing new protocols ? Let alon saving years of IETF work ?

    In the second session for MIP WG in Pittsburgh, Andrew Campbell mentioned
    that he was a co-author on a paper that did an evaluation / comparison of the various
    mobility management schemes. I've read that paper, and on the handoff issue, it was
    concluded that there were no significant differences between HMIP, CIP and HAWAII.
    Andrew also mentioned that in is presentation.
    I may also add that the simulations in that paper did not consider the Fast Handoffs
    draft (draft-elmalki- ...) which adds improvements to standard HMIP.
    So when I hear this direct association between micro mobility and fast handoffs, I get
    a bit confused.



------_=_NextPart_001_01C02FD2.A5999F80-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 18:57: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 SAA14386 for ; Fri, 6 Oct 2000 18:57:42 -0400 (EDT) Received: from standards (47.234.32.16:4898) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F235@standards.nortelnetworks.com>; Fri, 6 Oct 2000 18:41:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33337 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 18:41:13 -0400 Received: from qhars002.nortel.com (47.101.112.102:50829) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F234@standards.nortelnetworks.com>; Fri, 6 Oct 2000 18:41:12 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Fri, 6 Oct 2000 23:55:01 +0100 Received: from zcard00m.ca.nortel.com by smtprch1.nortel.com; Fri, 6 Oct 2000 17:53:10 -0500 Received: by zcard00m.ca.nortel.com with Internet Mail Service (5.5.2652.35) id <4KW0C23L>; Fri, 6 Oct 2000 18:42:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02FDF.70CD7760" Message-ID: <488891341182D4118A870000F80822E70128ED32@zcard00p.ca.nortel.com> Date: Fri, 6 Oct 2000 17:50:28 -0400 Reply-To: Abderrahmane Lakas Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Abderrahmane Lakas Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt X-To: "Casati, Alessio (Alessio)" 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_01C02FDF.70CD7760 Content-Type: text/plain; charset="ISO-8859-1" Alessio, First let me say that I agree this section might have introduced some confusion. It is only meant to capture the requirements of message ordering for authentication as defined by mobile IP, in case the PDP is involved in "handling" authentication extensions. The PDP's involvement may be, for example, in acting as an "attendant" (on behalf of the mobility agent) to the AAA server before making any policy decision. As I stated it in my first email, during the writing of this draft, it was not clear (still is not) for us how AAA would interact with a policy server to handle common situations. But one should agree that it is hard to see that section 4 describes any AAA mechanism, or explains the AAA model for MIP. - Abderrahmane -----Original Message----- From: Casati, Alessio (Alessio) [mailto:acasati@LUCENT.COM] Sent: Wednesday, October 04, 2000 3:40 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt In particular, clarifying why you need this would be helpful... 4. Handling MIP authentication extensions If the PDP is delegated to perform authentication, the PEP MUST send the FLO for the registration message followed by an extension object, all encapsulated in a client SI object. The extension object MUST contain all extensions including the authentication extension that the PDP is required to process, in the order they appear in the message. See section 3.5 in [4] for the ordering and processing requirements of authentication extensions, and [5] for AAA requirements. If an authentication fails, the PDP is required to include the appropriate authentication failure code in the decision message. > ---------- > From: Casati, Alessio (Alessio)[SMTP:acasati@LUCENT.COM] > Reply To: Casati, Alessio (Alessio) > Sent: 04 October 2000 20:26 > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] FW: I-D > ACTION:draft-jaseem-rap-cops-mip-00.txt > > My question is: if some form of policy management will be performed using > COPS, what makes the PEP/PDP interaction inherently different > when mobile IP is used? > > I ask this question without having carefully read the draft, > but, if you have time, this could make your proposal's > scope clearer. > > > thanks > > > alessio > > > ---------- > > From: Abderrahmane Lakas[SMTP:alakas@NORTELNETWORKS.COM] > > Reply To: Abderrahmane Lakas > > Sent: 04 October 2000 19:29 > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: [MOBILE-IP] FW: I-D > > ACTION:draft-jaseem-rap-cops-mip-00.txt > > > > The comments to this draft are understood and well taken. Let me just > > clarify that our intent (authors) is neither to use COPS as a protocol > for > > AAA, nor to open up any AAA-COPS discussion on whatever aspects of > > management. > > > > COPS is used here for non-AAA related aspects of Mobile IP. In our > draft, > > we propose a way to notify the PDP with the presence of MN for which > > policy-related configurations may be applied. COPS looks at the relevant > > extensions in the registration messages in order to make policy-related > > decisions. The AAA extensions are handled by AAA authority. > > > > We understand that we may not have highlighted it enough in the draft, > but > > we are not in any way proposing AAA solution for Mobile IP. > > > > Our assumptions here is that AAA handles AAA things, and COPS handles > > policy-related things. It's not clear yet for us how both coordinate, > but > > we assume that the PDP needs to know an MN has attached to the mobility > > agent, and policies may need to be applied to it. For example, based on > > the received extensions, the PDP may decide to install the MN's QoS > > profile. Other extensions that are or will be defined in the future may > > require some policy-management through COPS. > > > > Finally, this proposal has merit only if COPS is used for policy > > management. > > > > - Abderrahmane > > > > -----Original Message----- > > From: pcalhoun@eng.sun.com [ mailto:Pat.Calhoun@ENG.SUN.COM] > > Sent: Wednesday, October 04, 2000 10:07 AM > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > > > > > Ok, I'll be the first one to reply, and if you don't mind, I'll take off > > the > > white gloves (not that I wear them *that* often). > > > > Why? > > > > The IETF has already decided that network access (and specifically > Mobile > > IP) > > authentication, authorization and accounting is done through the > protocol > > that > > was selected in the AAA WG. COPS was a potential protocol, and did not > > succeed. > > So may I ask why you insist on opening up the can of worms all over > > again? > > Hasn't the past 2 years of AAA run around been enough? > > > > Am I missing something obvious? Or are some COPS people refusing to let > > the > > AAA do its work? Or is causing confusion in the marketplace the ultimate > > goal? > > > > PatC > > > > > We have submitted a draft defining COPS usage for Mobile IP. The > > > announcement is attached below. We will appreciate any comments. > > > > > > - Muhammad Jaseemuddin > > > > > > > -----Original Message----- > > > > From: yaniv@iphighway.com [SMTP:yaniv@iphighway.com] > > > > Sent: Wednesday, October 04, 2000 7:19 AM > > > > To: rap@iphighway.com > > > > Subject: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > > > > > > > To: IETF-Announce: ; > > > > CC: rap@iphighway.com > > > > From: Internet-Drafts@ietf.org > > > > Reply-to: Internet-Drafts@ietf.org > > > > Subject: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > > > > Date: Wed, 04 Oct 2000 06:54:46 -0400 > > > > Sender: nsyracus@cnri.reston.va.us > > > > > > > > --NextPart > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > > directories. > > > > > > > > > > > > Title : COPS usage for Mobile IP (MIP) > > > > Author(s) : M. Jaseemuddin, A. Lakas > > > > Filename : draft-jaseem-rap-cops-mip-00.txt > > > > Pages : 14 > > > > Date : 03-Oct-00 > > > > > > > > Mobile IP is a protocol that is used to achieve transparent routing > > > > of IP packets to a mobile node. A mobile node obtains a care-of- > > > > address in the foreign network and registers that address with the > > > > home agent. The home agent as well as the foreign agent can apply > > > > policies to the mobile node registration. This draft defines COPS > > > > [1] usage for Mobile IPv4 [2]. It describes how COPS is used to > > > > control Mobile IP registration based on policies. It defines the > > > > interactions between the PEP and the PDP to handle Mobile IP > > > > registration messages. It also provides a guideline for mobility > > > > agents on how to use this COPS client with regards to the > > > > registration messages. > > > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-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: <20001003122806.I-D@ietf.org> > > > > > > > > ENCODING mime > > > > FILE /internet-drafts/draft-jaseem-rap-cops-mip-00.txt > > > > > > > > --OtherAccess > > > > Content-Type: Message/External-body; > > > > name="draft-jaseem-rap-cops-mip-00.txt"; > > > > site="ftp.ietf.org"; > > > > access-type="anon-ftp"; > > > > directory="internet-drafts" > > > > > > > > > > > > --OtherAccess-- > > > > > > > > --NextPart-- > > > > > ------_=_NextPart_001_01C02FDF.70CD7760 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] FW: I-D = ACTION:draft-jaseem-rap-cops-mip-00.txt

Alessio,

First let me say that I agree this section might have = introduced some confusion. It is only meant to capture the requirements = of message ordering for authentication as defined by mobile IP, in case = the PDP is involved in "handling" authentication extensions. = The PDP's involvement may be, for example, in acting as an = "attendant" (on behalf of the mobility agent) to the AAA = server before making any policy decision.

As I stated it in my first email, during the writing = of this draft, it was not clear (still is not) for us how AAA would = interact with a policy server to handle common situations. But one = should agree that it is hard to see that section 4 describes any AAA = mechanism, or explains the AAA model for MIP.

- Abderrahmane

-----Original Message-----
From: Casati, Alessio (Alessio) [mailto:acasati@LUCENT.COM]=
Sent: Wednesday, October 04, 2000 3:40 PM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] FW: I-D = ACTION:draft-jaseem-rap-cops-mip-00.txt


In particular, clarifying why you need this = would
be helpful...


4. Handling MIP authentication extensions

If the PDP is delegated to perform = authentication,
the PEP MUST send the FLO for the registration = message
 followed by an extension object, all = encapsulated in a client
SI object. The extension object MUST contain all = extensions
 including the authentication extension that = the PDP is required
to process, in the order they appear in the = message.
See section 3.5 in [4] for the ordering and = processing requirements
of authentication extensions, and [5] for AAA = requirements.
If an authentication fails, the PDP is required to = include
the appropriate authentication failure code in the = decision message.

> ----------
> = From:         Casati, Alessio = (Alessio)[SMTP:acasati@LUCENT.COM]
> Reply To:     Casati, = Alessio (Alessio)
> = Sent:         04 October 2000 = 20:26
> To:   = MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: = [MOBILE-IP] FW: I-D
> ACTION:draft-jaseem-rap-cops-mip-00.txt
>
> My question is: if some form of policy = management will be performed using
> COPS, what makes the PEP/PDP interaction = inherently different
> when mobile IP is used?
>
> I ask this question without having carefully = read the draft,
> but, if you have time, this could make your = proposal's
> scope clearer.
>
>
> thanks
>
>
> alessio
>
> > ----------
> > = From:         Abderrahmane = Lakas[SMTP:alakas@NORTELNETWORKS.COM]
> > Reply To:     = Abderrahmane Lakas
> > = Sent:         04 October 2000 = 19:29
> > To:   = MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> > Subject:      Re: = [MOBILE-IP] FW: I-D
> > = ACTION:draft-jaseem-rap-cops-mip-00.txt
> >
> > The comments to this draft are understood = and well taken. Let me just
> > clarify that our intent (authors) is = neither to use COPS as a protocol
> for
> > AAA, nor to open up any AAA-COPS = discussion on whatever aspects of
> > management.
> >
> > COPS is used here for non-AAA related = aspects of Mobile IP. In our
> draft,
> > we propose a way to notify the PDP with = the presence of MN for which
> > policy-related configurations may be = applied. COPS looks at the relevant
> > extensions in the registration messages in = order to make policy-related
> > decisions. The AAA extensions are handled = by AAA authority.
> >
> > We understand that we may not have = highlighted it enough in the draft,
> but
> > we are not in any way proposing AAA = solution for Mobile IP.
> >
> > Our assumptions here is that AAA handles = AAA things, and COPS handles
> > policy-related things. It's not clear yet = for us how both coordinate,
> but
> > we assume that the PDP needs to know an MN = has attached to the mobility
> > agent, and policies may need to be applied = to it. For example, based on
> > the received extensions, the PDP may = decide to install the MN's QoS
> > profile. Other extensions that are or will = be defined in the future may
> > require some policy-management through = COPS.
> >
> > Finally, this proposal has merit only if = COPS is used for policy
> > management.
> >
> > - Abderrahmane
> >
> > -----Original Message-----
> > From: pcalhoun@eng.sun.com [ mailto:Pat.Calhoun@ENG.SUN.COM]
> > Sent: Wednesday, October 04, 2000 10:07 = AM
> > To: = MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: [MOBILE-IP] FW: I-D = ACTION:draft-jaseem-rap-cops-mip-00.txt
> >
> >
> > Ok, I'll be the first one to reply, and if = you don't mind, I'll take off
> > the
> > white gloves (not that I wear them *that* = often).
> >
> > Why?
> >
> > The IETF has already decided that network = access (and specifically
> Mobile
> > IP)
> > authentication, authorization and = accounting is done through the
> protocol
> > that
> > was selected in the AAA WG. COPS was a = potential protocol, and did not
> > succeed.
> >  So may I ask why you insist on = opening up the can of worms all over
> > again?
> > Hasn't the past 2 years of AAA run around = been enough?
> >
> > Am I missing something obvious? Or are = some COPS people refusing to let
> > the
> > AAA do its work? Or is causing confusion = in the marketplace the ultimate
> > goal?
> >
> > PatC
> >
> > > We have submitted a draft defining = COPS usage for Mobile IP. The
> > > announcement is attached below. We = will appreciate any comments.
> > >
> > > - Muhammad Jaseemuddin
> > >
> > > > -----Original = Message-----
> > > > From: yaniv@iphighway.com = [SMTP:yaniv@iphighway.com]
> > > > Sent: Wednesday, October 04, = 2000 7:19 AM
> > > > To:   = rap@iphighway.com
> > > > = Subject:      I-D = ACTION:draft-jaseem-rap-cops-mip-00.txt
> > > >
> > > > To: IETF-Announce: ;
> > > > CC: rap@iphighway.com
> > > > From: = Internet-Drafts@ietf.org
> > > > Reply-to: = Internet-Drafts@ietf.org
> > > > Subject: I-D = ACTION:draft-jaseem-rap-cops-mip-00.txt
> > > > Date: Wed, 04 Oct 2000 06:54:46 = -0400
> > > > Sender: = nsyracus@cnri.reston.va.us
> > > >
> > > > --NextPart
> > > >
> > > > A New Internet-Draft is = available from the on-line Internet-Drafts
> > > > directories.
> > > >
> > > >
> > > = >       = Title           : = COPS usage for Mobile IP (MIP)
> > > = >       = Author(s)       : M. Jaseemuddin, A. = Lakas
> > > = >       = Filename        : = draft-jaseem-rap-cops-mip-00.txt
> > > = >       = Pages           : = 14
> > > = >       = Date            = : 03-Oct-00
> > > >
> > > > Mobile IP is a protocol that is = used to achieve transparent routing
> > > > of IP packets to a mobile node. = A mobile node obtains a care-of-
> > > > address in the foreign network = and registers that address with the
> > > > home agent. The home agent as = well as the foreign agent can apply
> > > > policies to the mobile node = registration. This draft defines COPS
> > > > [1] usage for Mobile IPv4 [2]. = It describes how COPS is used to
> > > > control Mobile IP registration = based on policies. It defines the
> > > > interactions between the PEP and = the PDP to handle Mobile IP
> > > > registration messages. It also = provides a guideline for mobility
> > > > agents on how to use this COPS = client with regards to the
> > > > registration messages.
> > > >
> > > > A URL for this Internet-Draft = is:
> > > > http://www.ietf.org/internet-drafts/draft-jaseem-rap-c= ops-mip-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-jaseem-rap-cops-mip-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-jaseem-rap-cops-mip-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
> > > >     &nbs= p; "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=3D"OtherAccess"
> > > >
> > > > --OtherAccess
> > > > Content-Type: = Message/External-body;
> > > = >       = access-type=3D"mail-server";
> > > = >       = server=3D"mailserv@ietf.org"
> > > >
> > > > Content-Type: text/plain
> > > > Content-ID:   = <20001003122806.I-D@ietf.org>
> > > >
> > > > ENCODING mime
> > > > FILE = /internet-drafts/draft-jaseem-rap-cops-mip-00.txt
> > > >
> > > > --OtherAccess
> > > > Content-Type: = Message/External-body;
> > > = >       = name=3D"draft-jaseem-rap-cops-mip-00.txt";
> > > = >       = site=3D"ftp.ietf.org";
> > > = >       = access-type=3D"anon-ftp";
> > > = >       = directory=3D"internet-drafts"
> > > >
> > > >
> > > > --OtherAccess--
> > > >
> > > > --NextPart--
> >
> >
>

------_=_NextPart_001_01C02FDF.70CD7760-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 21:11: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 VAA16088 for ; Fri, 6 Oct 2000 21:11:52 -0400 (EDT) Received: from standards (47.234.32.16:4006) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F301@standards.nortelnetworks.com>; Fri, 6 Oct 2000 20:55:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33597 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 20:55:23 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F2F9@standards.nortelnetworks.com>; Fri, 6 Oct 2000 20:45:22 -0400 Received: from m3.gcn.net.tw (IDENT:root@m3.gcn.net.tw [203.77.71.25]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id TAA29729 for ; Fri, 6 Oct 2000 19:59:53 -0500 (CDT) Received: from folks.at-taiwan.com (folks.at-taiwan.com [203.77.2.142]) by m3.gcn.net.tw (8.9.3/8.9.3) with ESMTP id IAA30643 for ; Sat, 7 Oct 2000 08:59:38 +0800 Received: from [63.24.129.129] by folks.at-taiwan.com (Netscape Mail Server v2.02) with SMTP id AAG41306; Fri, 6 Oct 2000 22:35:57 +0800 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <0000295e445e$00005d39$000038e9@> Date: Fri, 6 Oct 2000 09:28:07 -0400 Reply-To: foreverwealthy@USA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: foreverwealthy@USA.COM Subject: [MOBILE-IP] DEALS DEALS DEALS!!! X-To: Undisclosed.Recipients@m3.gcn.net.tw To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: quoted-printable

$149.00 Special

WHILE SUPPLIES LAST ON A FIRST COME FIRST SERVE BASIS

PRICE IS PER PERSON BASED ON DOUBLE OCCUPANCY

BAHAMAS 3 DAY 2 NIGHT

Bahamas cruise and island vacation!

Stay at the beautiful Princess/Bahamia Resort and Casino

-Double Occupancy + Port and service fees



Ft. Lauderdale 4 Days/3 Nights

At the Holiday Inn Lauderdale by the sea



BONUS FOR R= ESERVING TODAY:

additional trip to:

ORLANDO 3 Days/2 Nights

Near the main gates of Disney

The vacations can be taken at any time, and are 100%= transferable.

This offer is only valid during this sellout.

For Reservations Call Now: Ask for the $149.00 Special

Toll Free: 1-800-261-7064 CALL Monday= -Friday 9-5

______________________________________________________= ________________

Looking to get= your business on the web?

$89.00 Incredible Special<= FONT SIZE=3D3 PTSIZE=3D10>

Free Web Hosting plus:

Bonus for Registering NOW! 3 Day-2 Night Vacation to LAS VEGAS!!!

Plus $500 = for chips, drinks, meals, show tickets, slot p= lay, etc.

For a limited time only, our web site company = is creating a custom 4 page Web Site for you to increase public awareness = of our company. Our 2000 advertising budget has been dedicated to the suc= cess of this program. In order to participate in this very limited promot= ion vacation give away, we only ask that you host your new site on our sta= te of the art high-speed servers for the first year.

Call Today for this incredible Offer: Toll-Free 1-800-261-7064 Monday-Friday 9-5

___________________________________________________________________
Your e-mail address was giving to us as someone who may be interested in t= he offers above. This is a one-time offer and you will not rece= ive this e-mail again, but if you would like to be removed from our Va= cation Package list please click here. Calling the toll-free number and/or pressing= reply to this e-mail will not get you removed. Thank you for your = time, and one again. This is a one-time offer!!!







 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 22:14: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 WAA17433 for ; Fri, 6 Oct 2000 22:14:46 -0400 (EDT) Received: from standards (47.234.32.16:2354) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F3B2@standards.nortelnetworks.com>; Fri, 6 Oct 2000 21:58:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33855 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 21:58:24 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:42759) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F3B1@standards.nortelnetworks.com>; Fri, 6 Oct 2000 21:58:23 -0400 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 MAA03876; Sat, 7 Oct 2000 12:10:13 +1000 (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 NAA23066; Sat, 7 Oct 2000 13:12:27 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Sat, 7 Oct 2000 13:12:35 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03004.0A537D20" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB330@eaubrnt018.epa.ericsson.se> Date: Sat, 7 Oct 2000 13:12:27 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] Are requirements required? X-To: Sandy Thuel 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_01C03004.0A537D20 Content-Type: text/plain Hi Sandy, > > Sorry I didn't get to your email sooner. > > => I was guessing that's what was on your mind, may I ask why > fast handoff = micromobility ? > If we can achieve the performance targets that we're aiming for > using MIP and some extensions wouldn't that be better and much less > complex than inventing new protocols ? Let alon saving years of IETF > work ? > > I think we have a terminology problem that is causing all this > confusion so let me take a stab at defining these terms based on your > comments and please correct me if I have misunderstood you: > > fast handoff support: approaches to enhance the handover performance > of Mobile IP by using existing Mobile IP mechanisms possibly with some > extensions. > > micro-mobility support: approaches to enhance handover performance > of Mobile IP by defining new protocols that work in conjunction with > Mobile IP while not adhering to conventional Mobile IP mechanisms. > > Is this a reasonable definition for starters? If so, we can then discuss > the relative merits and disadvantages of each. > => I'm not sure if managing micro mobility necessarily means that new protocols are needed. Perhaps MIP with some optimisation can do the job, or perhaps L2 can. I just wanted to emphasise two points: - The definition of micromobility should be generic and independant of what protocol will be used to solve it, MIP or not. We need to know the problem first before we can say protocol X will fix it. - I was questioning the statement you made earlier about fast handoffs = micromobility (new protocols). I'm not sure whether that is necessarily true always. Cheers, Hesham ------_=_NextPart_001_01C03004.0A537D20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] Are requirements required?

    Hi Sandy,

    =A0
    Sorry I didn't get = to your email sooner.

      =3D> I was = guessing that's what was on your mind, may I ask why
      fast handoff =3D = micromobility ?
      If we can achieve the = performance targets that we're aiming for
      using MIP and some = extensions wouldn't that be better and much less
      complex than = inventing new protocols ? Let alon saving years of IETF work = ?=A0=A0

      I think we have a = terminology problem that is causing all this confusion so let me take a = stab at defining these terms based on your comments and please correct = me if I have misunderstood you:

      fast handoff = support: approaches to enhance the handover performance of Mobile IP by = using existing Mobile IP mechanisms possibly with some = extensions.=A0

      micro-mobility = support: approaches to enhance handover performance of Mobile IP by = defining new protocols that work in conjunction with Mobile IP while = not adhering to conventional Mobile IP mechanisms.

    Is this a reasonable = definition for starters?=A0 If so, we can then discuss the relative = merits and disadvantages of each.

    =3D> I'm not sure = if managing micro mobility necessarily means that new protocols
    are needed. Perhaps = MIP with some optimisation can do the job, or perhaps L2
    can. I just wanted = to emphasise two points:

    - The definition of = micromobility should be generic and independant of what protocol
    will be used to = solve it, MIP or not. We need to know the problem first before we can =
    say protocol X will = fix it.

    - I was questioning = the statement you made earlier about
    fast handoffs =3D = micromobility (new protocols). I'm not sure whether that is = necessarily
    true always. =

    Cheers,
    Hesham


------_=_NextPart_001_01C03004.0A537D20-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 22:25: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 WAA17497 for ; Fri, 6 Oct 2000 22:25:29 -0400 (EDT) Received: from standards (47.234.32.16:2354) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F40B@standards.nortelnetworks.com>; Fri, 6 Oct 2000 22:08:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33972 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 22:08:54 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:42832) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F40A@standards.nortelnetworks.com>; Fri, 6 Oct 2000 22:08:52 -0400 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 MAA04010; Sat, 7 Oct 2000 12:20:44 +1000 (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 NAA23459; Sat, 7 Oct 2000 13:22:57 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Sat, 7 Oct 2000 13:23:05 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03005.813619B0" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB331@eaubrnt018.epa.ericsson.se> Date: Sat, 7 Oct 2000 13:22:56 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac hes X-To: "pcalhoun@eng.sun.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_001_01C03005.813619B0 Content-Type: text/plain > > > > The point is that any further specification of the above interaction > > of L2/L3 would bring in L2 issues specific to a certain > wireless/cellular > > system which is what we decided was out of scope. I think that the > > above explanation is quite clear. > > We need to be careful in setting the scope. In my opinion, what is out of > scope is a solution that cannot work with known wireless technologies. > => I'm sure you have a good reason for saying that, but could you please tell us exactly why this can not work with known wireless technologies ? ------_=_NextPart_001_01C03005.813619B0 Content-Type: text/html RE: [MOBILE-IP] Differences between the two MIPv4 handoff approac hes

    >
    > The point is that any further specification of the above interaction
    > of L2/L3 would bring in L2 issues specific to a certain wireless/cellular
    > system which is what we decided was out of scope. I think that the
    > above explanation is quite clear.

    We need to be careful in setting the scope. In my opinion, what is out of
    scope is a solution that cannot work with known wireless technologies.

    => I'm sure you have a good reason for saying that, but could you
    please tell us exactly why this can not work with known wireless
    technologies ?

------_=_NextPart_001_01C03005.813619B0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Oct 8 06:01: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 GAA07755 for ; Sun, 8 Oct 2000 06:01:17 -0400 (EDT) Received: from standards (47.234.32.16:1853) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F894@standards.nortelnetworks.com>; 8 Oct 2000 5:44:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35540 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 8 Oct 2000 05:44:19 -0400 Received: from mail2.mia.bellsouth.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F892@standards.nortelnetworks.com>; 8 Oct 2000 5:34:18 -0400 Received: from www.goldendeckcasino.com (adsl-61-143-206.mia.bellsouth.net [208.61.143.206]) by mail2.mia.bellsouth.net (3.3.5alt/0.75.2) with SMTP id FAA29331; Sun, 8 Oct 2000 05:47:51 -0400 (EDT) X-Sender: bubblehead32@hotmail.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <200010080947.FAA29331@mail2.mia.bellsouth.net> Date: Sun, 8 Oct 2000 05:41:05 -0400 Reply-To: bubblehead32@HOTMAIL.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: bubblehead32@HOTMAIL.COM Subject: [MOBILE-IP] WOW!!! Highest Payouts Around!!!!!!!! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Its just like being there. Go to www.goldendeckcasino.com/goldendeckcasino/links/2769.html. If you would like to be removed from these mailings in the future please mailto:bubblehead32@hotmail.com?subject=remove From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Oct 8 09:01: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 JAA08925 for ; Sun, 8 Oct 2000 09:01:33 -0400 (EDT) Received: from standards (47.234.32.16:4872) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F913@standards.nortelnetworks.com>; 8 Oct 2000 8:45:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35712 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 8 Oct 2000 08:45:01 -0400 Received: from noya.bupt.edu.cn by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F912@standards.nortelnetworks.com>; 8 Oct 2000 8:34:59 -0400 Received: from tmq ([202.112.111.70]) by noya.bupt.edu.cn (8.11.0/8.10.1) with SMTP id e98CmkG27987 for ; Sun, 8 Oct 2000 20:48:46 +0800 (CST) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0029_01C03169.A886AF60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Message-ID: <002b01c03126$9da92480$466f70ca@tmq> Date: Sun, 8 Oct 2000 20:52:23 +0800 Reply-To: tmq Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: tmq Subject: [MOBILE-IP] subscibe To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C03169.A886AF60 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 c3Vic2NyaWJlIG1vYmlsZS1pcCBNaW5xaWFuZyBUYW4NCg0K ------=_NextPart_000_0029_01C03169.A886AF60 Content-Type: text/x-vcard; name="mola_sina.vcf" Content-Disposition: attachment; filename="mola_sina.vcf" Content-Transfer-Encoding: 7bit BEGIN:VCARD VERSION:2.1 N:;mola_sina FN:mola_sina EMAIL;PREF;INTERNET:mola1222@sina.com REV:20001008T125223Z END:VCARD ------=_NextPart_000_0029_01C03169.A886AF60-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Oct 8 18:09: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 SAA11647 for ; Sun, 8 Oct 2000 18:09:20 -0400 (EDT) Received: from standards (47.234.32.16:3343) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9FB1B@standards.nortelnetworks.com>; 8 Oct 2000 17:54:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36431 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 8 Oct 2000 17:54:13 -0400 Received: from xjf.xjfi.net (szptt103-190.szptt.net.cn) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9FB0B@standards.nortelnetworks.com>; 8 Oct 2000 17:44:11 -0400 Received: from pavilion (mig-fl29a-49.rasserver.net [206.214.131.49]) by xjf.xjfi.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id 4PRZH0L5; Mon, 9 Oct 2000 06:06:21 +0800 Message-ID: Date: Sun, 8 Oct 2000 17:54:13 -0400 Reply-To: rsb@DOCSJ.DE Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: rsb@DOCSJ.DE Subject: [MOBILE-IP] At last, HERBAL V the all natural alternative! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Herbal V: An Incredible All-Natural Healthy Alternative Herbal V is the All Natural Approach to Male Virility, Vitality and Pleasure. Available N o w ! Welcome to the New Sexual Revolution. It's the all natural male potency and pleasure pill that men everywhere are buzzing about. Herbal V is safe, natural and specifically formulated to help support male sexual function and pleasure. You just take two easy-to-swallow tablets one hour before sex. And there's more great news - you can get Herbal V for less than $1 a pill. Amazing word of mouth praise on Herbal V has been spreading like wildfire-already over 1,500,000 men have chosen Herbal V. Since it is 100% natural you will never have to worry about safety. Try doctor-recommended Herbal V today and have the greatest night of your life! Herbal V... Bringing Back the Magic! 1,585,000 men can't be wrong. To date over 1 million men have tried the super supplement Herbal V. Here is why: No Doctor Visit Required Available Over the Counter Not a Drug 100% Natural Safe, No Worries Highest Quality Pharmaceutical-Grade Pure Nutriceuticals Guaranteed Potency & Purity Be a Real Man Again! Questions and Answers What is Herbal V? Herbal V is a proprietary blend that was specifically developed as a safe alternative for men who prefer an all-natural approach to address impotence and boost sexual performance. This amazing formula first became popular with Hollywood insiders and the wealthy elite. They were maximizing their sex lives, long before it was available to the general public. How does Herbal V work? Developed by a team whose goal was to create the perfect all-natural aphrodisiac. Herbal V is the result of that remarkable effort. The Herbal V formula contains a precise blend of cutting edge pro-sexual nutrients from around the world that provide nutritional support, making it possible for a man to have a pleasurable sexual experience. What can Herbal V do for me? Herbal V helps support male sexual function and pleasure in a safe and natural manner. Simply put, it can make your sex life incredible. Is Herbal V Safe? One of the great things about Herbal V is that it is not a drug. It is an incredible herbal dietary supplement that provides nutritional support for male sexual function and pleasure. One of the most comforting features of Herbal V is that you never have to worry about safety. Herbal V: Safe - Natural - Exciting Many have speculated that because Herbal V is so popular with men, it must contain prescription drugs or chemical components. Herbal V does not contain any elements or traces of any prescription drug. Herbal V is made using the world's most technologically advanced state-of-the-art cold processing equipment to ensure maximum purity. Herbal V has been independently analyzed by the nation's premier testing facility to ensure purity, quality and to end the rumors that, because it is so popular, it must somehow be chemical. It is not. Herbal V is natural - just as it says on the label. Herbal V is simply fantastic! Herbal V: Ingredients Yohimbe, saw palmetto, avena sativa, androstenedione, guarana, taurine, siberian ginseng, tribulus terrestris. Tribulus Terrestis is certified to enhanced testosterone levels by increasing Luteinzing hormone (LH) levels. Androstenedione which is a precursor to testosterone unlocks bound testosterone and makes it biologically active again quickly. This means a dramatic surge in desire. Avena Sativa Stimulates the neurotransmitter pleasure centers to maximum capacity. This greatly intensifies pleasure. Just listen to what Herbal V has done for the sex lives of people like you! “On a scale of 1 to 10, it's a 15. Electrifying. It's like a wonder pill!” — Justin Q B., New Haven, Texas “I haven't had sexual relations in 11 years. Then with Herbal V it was... wow! It works again!” — Sid R., Lakeland, Florida “I had sex four times in one night. It made me feel like a 19-year-old again.” — Chip S, Beech Mountain, North Carolina “Herbal V has turned my husband into a Sexual Superman! I like the fact that it's all natural and has no side effects. It's bringing back the good old days.” — Jennifer B, Beverly Hills, California The above testimonials are from product literature, and we have not independently verified them. However, the following testimonial is from a "senior" gentleman who has purchased his second bottle of Herbal V. When we heard his words with our own ears, we asked his permission to print them here. “Man! I'm wild as I can be! I feel like I'm 25 years old again! I'm not believing this!” — Mr. Murphy, age 64, Lampart, IL. Risk Free: Double Your Money Back Guarantee If Herbal V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked ! Order Now: Safe, Fast, Secure, Private Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express.payments. Money Orders are accepted only by Postal Mail. Each bottle of Herbal V contains 30 tablets, approximately a 1 month supply. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Herbal V $24 ______ 2 Bottles of Herbal V $44 ______ 3 Bottles of Herbal V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ] International Orders Please add $16 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ] Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: LSN 3502 N. Powerline Rd. #525 Pompano Beach, FL 33069 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Herbal V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Herbal V helps provide herbal and nutritional support for male sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 9 05:42: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 FAA00139 for ; Mon, 9 Oct 2000 05:42:44 -0400 (EDT) Received: from standards (47.234.32.16:3491) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9FD0A@standards.nortelnetworks.com>; Mon, 9 Oct 2000 5:25:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37123 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 9 Oct 2000 05:25:57 -0400 Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9FD09@standards.nortelnetworks.com>; Mon, 9 Oct 2000 5:25:57 -0400 Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA28212 for ; Mon, 9 Oct 2000 05:40:39 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA28133 for ; Mon, 9 Oct 2000 05:40:34 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <4MGP7DGM>; Mon, 9 Oct 2000 10:40:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C0487733D@en0060exch001u.uk.lucent.com> Date: Mon, 9 Oct 2000 10:40:05 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Abderrahmane; > First off, thanks for your answer. > Alessio, > > First let me say that I agree this section might have introduced some > confusion. It is only meant to capture the requirements of message > ordering for authentication as defined by mobile IP, in case the PDP is > involved in "handling" authentication extensions. The PDP's involvement > may be, for example, in acting as an "attendant" (on behalf of the > mobility agent) to the AAA server before making any policy decision. > > I agree with you the current text may have generated some confusion. I would suggest, if you have time, you provide an applicability example, based on current mobile IP extension, of the proposed COPS-MIP client. This would be very helpful to fully understand your proposal and to let the Mobile IP list to evaluate it and provide useful comments. > As I stated it in my first email, during the writing of this draft, it was > not clear (still is not) for us how AAA would interact with a policy > server to handle common situations. But one should agree that it is hard > to see that section 4 describes any AAA mechanism, or explains the AAA > model for MIP. > I agree that the section does not describe an AAA model for MIP. In fact, the AAA model for MIP is well defined, and this proposal would seem to try to comply with it. That's why there are voices expressing the worry that this would introduce some overlap/conflict with the work currently ongoing in the AAA WG (where after two year a protocol has been selected to base AAA for network access on). Your text hints to the possibility to use the PDP to perform authentication. We need to have a clear understanding of this and other applicability cases of your proposal. You would probably have to bring to the list cases (or a single case) supporting the necessity of your proposal. Could you please do that as soon as you have some leftover time? I'd wholeheartedly support any proposals of necessary building blocks to support policy control in conjunction with mobile IP. I have to understand whether this is one such building block we are missing. Thanks alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 9 08:14: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 IAA02255 for ; Mon, 9 Oct 2000 08:14:43 -0400 (EDT) Received: from standards (47.234.32.16:4519) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9FE1B@standards.nortelnetworks.com>; Mon, 9 Oct 2000 7:57:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37432 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 9 Oct 2000 07:57:35 -0400 Received: from explore.kwangwoon.ac.kr (128.134.70.30:42203) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9FDF9@standards.nortelnetworks.com>; Mon, 9 Oct 2000 7:47:34 -0400 Received: from eos (eos.kwangwoon.ac.kr [128.134.56.162]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id UAA18296 for ; Mon, 9 Oct 2000 20:59:09 +0900 (KST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C03234.5A9E8400" 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 Message-ID: <001001c031e8$eb0ac860$a2388680@kwangwoon.ac.kr> Date: Mon, 9 Oct 2000 21:03:20 +0900 Reply-To: SungJin Lee Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: SungJin Lee Subject: [MOBILE-IP] Mobile node NAI-extension To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C03234.5A9E8400 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SXMgdGhlIE5BSS1leHRlbnNpb24gKFJGQzI3OTQpIHVzZWQgb25seSBmb3IgUFBQIGNvbm5lY3Rp b24gPw0KDQpvciBjb3VsZCBpdCBiZSB1c2VkIGZvciBub24tUFBQIGFuZCBnZW5lcmFsIGR5bmFt aWMgSVAgYWRkcmVzcyANCmFsbG9jYXRpb24gZm9yIG1vYmlsZSBJUCA/DQoNCklmIG5vdCwgcGxl YXNlIGxldCBtZSBrbm93IGlmIHRoZXJlIGlzIGFueSBvdGhlciBkeW5hbWljIElQIGFkZHJlc3Mg DQphbGxvY2F0aW9uIG1ldGhvZCBmb3IgbW9iaWxlIElQLg0K ------=_NextPart_000_000D_01C03234.5A9E8400 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQxMzQuNjAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+SXMgdGhlIE5B SS1leHRlbnNpb24gKFJGQzI3OTQpIHVzZWQgb25seSBmb3IgUFBQIGNvbm5lY3Rpb24gDQo/PC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTI+b3IgY291bGQgaXQgYmUgdXNlZCBmb3Igbm9uLVBQUCBhbmQgZ2VuZXJhbCBk eW5hbWljIElQIGFkZHJlc3MgDQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5hbGxv Y2F0aW9uIGZvciBtb2JpbGUgSVAgPzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPklmIG5vdCwgcGxlYXNlIGxldCBt ZSBrbm93IGlmJm5ic3A7dGhlcmUgaXMgYW55IG90aGVyIGR5bmFtaWMgDQpJUCBhZGRyZXNzIDwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPmFsbG9jYXRpb24gbWV0aG9kIGZvciBtb2Jp bGUgSVAuPC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_000D_01C03234.5A9E8400-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 9 10:15: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 KAA04462 for ; Mon, 9 Oct 2000 10:15:03 -0400 (EDT) Received: from standards (47.234.32.16:4398) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9FECF@standards.nortelnetworks.com>; Mon, 9 Oct 2000 9:58:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37716 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 9 Oct 2000 09:58:21 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9FECE@standards.nortelnetworks.com>; Mon, 9 Oct 2000 9:58:21 -0400 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA01977; Mon, 9 Oct 2000 08:12:33 -0600 (MDT) 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 HAA13161; Mon, 9 Oct 2000 07:12:32 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA21286; Mon, 9 Oct 2000 07:12:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 9 Oct 2000 07:10:06 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Mobile node NAI-extension X-To: SungJin Lee To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <001001c031e8$eb0ac860$a2388680@kwangwoon.ac.kr> > Is the NAI-extension (RFC2794) used only for PPP connection ? No, the RFC you state defines how the NAI is carried within Mobile IP, regardless of the access method. > > or could it be used for non-PPP and general dynamic IP address > allocation for mobile IP ? Correct. > > If not, please let me know if there is any other dynamic IP address > allocation method for mobile IP. The only (and best) one :) PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 9 10:46: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 KAA04990 for ; Mon, 9 Oct 2000 10:46:12 -0400 (EDT) Received: from standards (47.234.32.16:2682) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9FF3F@standards.nortelnetworks.com>; Mon, 9 Oct 2000 10:29:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37863 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 9 Oct 2000 10:29:31 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9FF3E@standards.nortelnetworks.com>; Mon, 9 Oct 2000 10:19:31 -0400 Received: from karen.intersol.com.au (karen.intersol.com.au [203.31.77.1]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id JAA16374; Mon, 9 Oct 2000 09:34:06 -0500 (CDT) Received: from arabia.com by karen.intersol.com.au via SMTP (950413.SGI.8.6.12/940406.SGI) id BAA01417; Tue, 10 Oct 2000 01:37:54 +1000 Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Message-ID: <797.638757.566790@china.com> Date: Mon, 9 Oct 2000 10:29:31 -0400 Reply-To: asmith1722@CHINA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: asmith1722@CHINA.COM Subject: [MOBILE-IP] Noone Can Put You In the Top 10 Positions on Search Engines Like Us To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Your business will make money 24-hours a day!



GET YOUR FREE REPORT OF YOUR WEBSITE'S POSITION ON MAJOR SEARCH ENGINES
By simply filling out the form below. This report will be the most important information you could have on driving traffic to your site.

INCREASE THE TRAFFIC TO YOUR WEBSITE BY 10 TO 20 TIMES
Until recently, only larger companies were able to afford the luxury of having their sites positioned. WE GUARANTEE, in writing, that you will be among those select few positioned or your MONEY BACK.

95% OF ALL PEOPLE USE SEARCH ENGINES TO FIND WHAT THEY WANT ON THE INTERNET.
Contrary to popular belief simply submitting your web site to the search engine does not guarantee that your site will even be indexed (or listed) at all!!!
WE GUARANTEE, in writing, that your traffic will increase or your MONEY BACK.

95% OF ALL PEOPLE WHO USE A MAJOR SEARCH ENGINE NEVER GO PAST THE TOP 20 LISTINGS
If you're not ranked within the top 10, or the top 20 positions in the major search engines using keywords and phrases directly related to your company, you lose. WE GUARANTEE in writing, your site will be in the top 10 or top 20 or your MONEY BACK.

SEARCH ENGINE PLACEMENT IS THE MOST EFFECTIVE METHOD TO INCREASE TRAFFIC TO YOUR SITE
Web positioning is the MOST IMPORTANT thing you can do for your website to increase traffic and sales. With over 800 million websites on the Internet, no one will find your site by simply "surfing the Net". WE GUARANTEE, in writing, your site will be in the top 10 or top 20 or your MONEY BACK

DON'T WAIT!!! GET YOUR FREE REPORT OF YOUR WEBSITE'S POSITION ON MAJOR SEARCH ENGINES
A Website Promoter will contact you within 24 hours, just fill out the form below.

 
Your Name:
Your Web Address:
Company Name:
State:
Business Phone:
Home Phone:
Email:
Type of Business:

 

If you received this in error or would like to
be removed from our list, PLEASE CLICK HERE

From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 9 11:09: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 LAA05351 for ; Mon, 9 Oct 2000 11:09:32 -0400 (EDT) Received: from standards (47.234.32.16:2682) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9FF99@standards.nortelnetworks.com>; Mon, 9 Oct 2000 10:49:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37976 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 9 Oct 2000 10:49:29 -0400 Received: from dv.op.dlr.de by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9FF92@standards.nortelnetworks.com>; Mon, 9 Oct 2000 10:39:21 -0400 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 e99ErpW52138 for ; Mon, 9 Oct 2000 16:53:51 +0200 Received: from zeus.nt.op.dlr.de (pcdn195_nt_op [129.247.173.195]) by zeus.nt.op.dlr.de (8.9.1b+Sun/8.9.1) with ESMTP id QAA20309 for ; Mon, 9 Oct 2000 16:53:50 +0200 (MET DST) X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------CB49B1CED950610369ECF7C6" Message-ID: <39E1DACE.B5DBE8E7@zeus.nt.op.dlr.de> Date: Mon, 9 Oct 2000 16:48:47 +0200 Reply-To: mberio@libero.it Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Matteo Berioli Subject: [MOBILE-IP] A practical question... To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------CB49B1CED950610369ECF7C6 Content-Type: multipart/alternative; boundary="------------EC1A0CF251C176391AE5186D" --------------EC1A0CF251C176391AE5186D Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I would appreciate very much any explanation. It's a little bit long, but I hope fast and clear! Thank you. PROBLEM: Let' s assume we have a Mobile Router, to which a Mobile Host attaches. We know how the matters work with IPv4 and Mobile IP (see RFC 2002 par: 4.5 page 61-62). The problem is here that we have a double re-direction of each packet directed to the Mobile Host. As a matter of fact, each packet has to pass through the Home Agent of the Mobile Host and then through the Home Agent of the Mobile Router. Let's assume, now, that the mobile network is an IPv6 network. In IPv6 could be this double re-direction avoided? I guess: 1° possibility A pool of IPv6 addresses is assigned to the Mobile Router when it desires to connect to the Internet; so the Mobile Router can assigned an its own Care-of Address to each Mobile Host asking for one. This allows the Mobile Host to inform by itself its Correspondent Nodes and its Home Agent of this new Care-of Address, and this avoids the double re-direction... 2° possibility A single IPv4 address is assigned to the Mobile Router as its Care-of Address, because, for example, the Edge Router to which the Mobile Router attaches doesn't support IPv6. Now the problem comes! It could be solved in this way (I wonder if it is possible and realistic...): when a Mobile Host attaches to the Mobile Router, it asks to the DHCP server, which is in the Mobile Router, for a Care-of Address, and sends its Home Address to it; the Mobile Router could use Stateful Address Autoconfiguration (setting M=1 in the Router Advertisement packets), and it could oblige all the hosts in the mobile network, to acquire the same Care-of Address, that is the one it got from the Edge Router!! So all the hosts, both fixed and mobile hosts, share one Care-of Address; but they don't care about this, because the Mobile Router set M=1 in the Router Advertisement packets, so avoiding Stateless Address Autoconfiguration and Duplicate Address Detection. So each host on the mobile network can inform by itself its Correspondent Nodes and its Home Agent of this new Care-of Address. Now when a packet arrives to the Mobile Router, obviously it will be encapsulated in an IPv4 packet (see figure in the attachment), so first of all the Mobile Router has to decapsulate it. Then if the packet comes from a Correspondent Node it will have, as Destination IP Address, the Care-of Address of the Mobile Router and in the Routing Header it will have the Home Address of the Mobile Host that is on the mobile network, and with which the Correspondent Node is communicating. The Mobile Router knows the Home Addresses of the Mobile Hosts it has in charge and knows to which link-layer addresses they are related; so the Mobile Router has to recognize this address in the Routing Header and it has to forward the packet directly in the local network to the Mobile Host. If the packet comes from the Home Agent of one Mobile Host that is attached to the mobile network, the matters are similar. The only difference is that the packet will be encapsulated in an IPv6 packet, too; therefore the Mobile Router has to decapsulate again the packet, again it has to recognize the Home Address of one Mobile Host it has in charge, and it has to forward the packet to it through its link-layer address. Probably the picture I made can clarify the problem. 1° possibility: [Image] 2° possibility: [Image] Thanks again to anyone will answer. Matteo Berioli --------------EC1A0CF251C176391AE5186D Content-Type: multipart/related; boundary="------------46B1D4483E2F15487BE06550" --------------46B1D4483E2F15487BE06550 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I would appreciate very much any explanation.
It's a little bit long, but I hope fast and clear!
Thank you.

PROBLEM: Let' s assume we have a Mobile Router, to which a Mobile Host attaches. We know how the matters work with IPv4 and Mobile IP (see RFC 2002 par: 4.5 page 61-62). The problem is here that we have a double re-direction of each packet directed to the Mobile Host. As a matter of fact, each packet has to pass through the Home Agent of the Mobile Host and then through the Home Agent of the Mobile Router.
Let's assume, now, that the mobile network is an IPv6 network. In IPv6 could be this double re-direction avoided?

I guess:

1° possibility
A pool of IPv6 addresses is assigned to the Mobile Router when it desires to connect to the Internet; so the Mobile Router can assigned an its own Care-of Address to each Mobile Host asking for one. This allows the Mobile Host to inform by itself its Correspondent Nodes and its Home Agent of this new Care-of Address, and this avoids the double re-direction...

2° possibility
A single IPv4 address is assigned to the Mobile Router as its Care-of Address, because, for example, the Edge Router to which the Mobile Router attaches doesn't support IPv6. Now the problem comes!
It could be solved in this way (I wonder if it is possible and realistic...):
when a Mobile Host attaches to the Mobile Router, it asks to the DHCP server, which is in the Mobile Router, for a Care-of Address, and sends its Home Address to it;
the Mobile Router could use Stateful Address Autoconfiguration (setting M=1 in the Router Advertisement packets), and it could oblige all the hosts in the mobile network, to acquire the same Care-of Address, that is the one it got from the Edge Router!!
So all the hosts, both fixed and mobile hosts, share one Care-of Address; but they don't care about this, because the Mobile Router set M=1 in the Router Advertisement packets, so avoiding Stateless Address Autoconfiguration and Duplicate Address Detection.
So each host on the mobile network can inform by itself its Correspondent Nodes and its Home Agent of this new Care-of Address.
Now when a packet arrives to the Mobile Router, obviously it will be encapsulated in an IPv4 packet (see figure in the attachment), so first of all the Mobile Router has to decapsulate it.
Then if the packet comes from a Correspondent Node it will have, as Destination IP Address, the Care-of Address of the Mobile Router and in the Routing Header it will have the Home Address of the Mobile Host that is on the mobile network, and with which the Correspondent Node is communicating.
The Mobile Router knows the Home Addresses of the Mobile Hosts it has in charge and knows to which link-layer addresses they are related; so the Mobile Router has to recognize this address in the Routing Header and it has to forward the packet directly in the local network to the Mobile Host.
If the packet comes from the Home Agent of one Mobile Host that is attached to the mobile network, the matters are similar. The only difference is that the packet will be encapsulated in an IPv6 packet, too; therefore the Mobile Router has to decapsulate again the packet, again it has to recognize the Home Address of one Mobile Host it has in charge, and it has to forward the packet to it through its link-layer address.

Probably the picture I made can clarify the problem.

1° possibility:


2° possibility:


 

Thanks again to anyone will answer.

Matteo Berioli --------------46B1D4483E2F15487BE06550 Content-Type: image/jpeg Content-ID: Content-Disposition: inline; filename="C:\TEMP\nsmailVS.jpeg" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAAR CAE9AqsDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD+/iiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK/IG8/4KF/FP 9r/4p+JPgt/wSZ0z9n/42eEvhr/whSfHr/goJ8UPFXiPxj+xt8LPEfiLxH4A1y7+DXwY0T4P z2ep/to/tAW/wS1rxP448UeEvBHxj+Dvws+D19f/AAz0r4l/G618W+LJvh9a9/8A8FCfEfx2 +Jvjv9mn9gL9nbx/8QPgX4g/a3/4XL41+Pf7S/w3s/Bx8d/Ar9jb9n3R/BVh8Z734Q694n8a 6Le+Df2gPir8Tfjb+z78EPhh4/0HwF8Vb74W6P8AEb4gfGGz8Oaf4g+HHhzVof0f8J+E/Cvg Lwr4Z8C+BfDPh/wX4J8F+H9G8J+DvB3hPRtO8OeFfCfhXw5p1to/h7wz4Z8PaPbWekaD4f0L SLOz0vRtG0uztdO0vTrW2sbG2gtoIolAPgDwn/wTwn17wr4Zl/at/bK/bf8A2mfjJp/h/RtK 8QfE/wAJ/tO/GX9hnwreT2mnWzata+GfgT+wB45/Zr+FOm+H7jxTN4i8Q6NqHj3R/in8ZbPT tftvB3in41+N/DfhHwZa6Dz/AMWf2A/+CYH7O/ws+Jfx0/4Z7+H/AOx54S+EXw/8ZfEv4o/G L9imz8f/ALGXxTtPhZ4B8Oal4w8babr/AMQv2GL/AOEnxt8cfD+30zRP+Ep1X4T/ANr+JPDn ibxH4Y8K63/whuseLfC3hG6039P6/MD/AIK8/wDBPbx3/wAFQ/2Nta/Y88I/tLf8Mw+H/HPx A8CeIvil4m/4U1o/xq/4TzwJ4DvrrxZp/wAOv7G1Pxr8P73wv5vxN0z4dePP+Eu8O+J7TWI/ +EC/4ReeC88P+KddtpADwD9grxN8U/if+yd8Kf2tP+Ccf7UfxA/ar/Zy+NH/AAnXjLwz+zp/ wU58Q+Iz478G/aviT4x0vWfhP4L/AG0PCfgbxz8evAX/AApXx1eeOPDPiPUv2hvB3/BRj/hY mj/CzwD8PPhL8S/h14Murn4za99v/sQ/tveFf2xfCvjjR9Y8D+IPgD+1H8AfEGnfD39rj9kf 4hajp198TP2d/iZfac2p6Zb3Gp6YsWkfEf4P/EfSIpfGPwB+P3g6KT4e/G74eyQ+IfD02na5 p3i7wj4U/nh/4M/P2O/in8E/2E0/an/4aQ/4S/4Jfto/8JX4j/4Zi1L4eeI7P/hTvxT+C3xi +IvwT/4T/wAG/EL/AIXHf+Err/hZXhLwds+Jdn/wo/SfEfiL+xfhPY/8Jrb6Z8Lvsniz9vv+ Cgn7JfjvxVrHw+/bl/Y88M/8bB/2XP7Di8EW2lfEPR/hDa/tXfs4/wDCd6J4m+OX7C3xp8Wa /wCDvHHhLW/h/wDFvwlb+J7r4OX3jvw/9l+CP7R0ngf4reF/Gfw2t/8AhO9Z1YA/T+ivAP2X P2kPAn7W/wACfA3x++HWj/EDwv4f8Z/8JNpmoeCfiz4I1j4b/FP4c+O/h/4x8Q/Db4pfC34l +BtdjW98N/ED4XfE3wh4u+HvjLT4LjU9HHiPw1qU3h3XfEHh+XTNc1D3+gAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD84P2DLnxV8XviF+21+1v4 /wBG8P6Vq/xD/af+Jn7Kfwit9G8Tajr2o6H+zB/wT4+JnxM/Zz8LeH/FkJ8J+C9DtfEHiP8A ajg/bI+P1sbay8XeINN8K/Hzwz4G1v4m+KdI8C+FdD8Hfo/XwB/wTg+KWj/E/wCC/wAao7LX fh/qfiD4b/t//wDBS34W+NdG8AaZ4E8P/wDCG6x4X/b6/aKufDeheNfDPgDT9IstI+IGr/DL V/AHj3xHqfiPTYvHfxE/4TOz+LfjXUPEviD4gXnizXvAPB//AAXR/wCCcfxX/bs+Dv8AwT0+ AXxl/wCGj/jb8Xv+Fhf8Vb8C7bS/G/wJ8A/8IB8Hbr43f8VT8Zf7c07wl4q/4Srwlp2s6Zon /ClZ/iz/AGH4x0PV/CvxH/4QPU7TY4B9/wD7SH7Qmj/s4eBNH8V3PgP4gfF7xb4x+IHgj4W/ DH4KfCFfAl18Xfiz478b6xHaroXw/wBK+I/jv4a+Er//AIQ7wla+LPi98SNT1nxnoej+APgn 8Nfif8VPE2oWHhLwH4g1C0/ODWfhD/wW8/aZ+DXhPXL/APbW/Zg/4Jl/ETxJ4gufHeo/DD4N /sZWn7X3xC+FvhW9n8TL4Y+Bvj747fGb9pJ/g38VPEGjeG9W8MTfFDxv8Nf2c/h7p138TPDd 7b/DnX7n4dh7rxd6/wDHj4W+BPiB/wAFcP8Agm94s8XaF/a/iD4Hfsgf8FPfil8LdQ/tPWLD /hF/Her+N/8AgnR8FNQ137LpmoWVlrf2j4ZfGD4i+Gf7M8RW2r6PF/wkX9swafF4g0jQtV0z 6A/aX/bM+FnwB/tb4aaF4i+H/wATf2x/EHw/v/FP7Pf7FNn8TfDnh/47ftB+I73+3tK8CaR4 c8KLF4g8W+H/AIf+IPFvh/U9N8a/HTUPBt78LPgt4O8P+P8A4s/FLW/D/wAN/hl481/QwD+U L/ggr+xp/wAFYfiv/wAEnv2U/H/7NH/BaD/hk34Ja/8A8Lz/AOEK/Z//AOHdP7Nvx3/4QH+y /wBpP4xaL4j/AOLreP8AxRp3i3xV/wAJV4t07XvGv/E2sof7D/4SP/hHLDzNM0eylc/4Nuv+ CbP/AAXm/Zf/AOEC8XfGr9ob/hl/9iV/7N17/hiP46aZN8c/GPjDw5qvleMfsHhb4Z/8JFo/ /DGX/CT/APC3fiP4i1vVtG+Ivg/4p6V8dvBmkQfH39mj4heGofsE39Pv/BLH9in/AId2/wDB Pv8AZe/Y6udf/wCEo8QfB/4fz/8ACea7Bqv9t6PffFP4geJ9f+KXxa/4RHU5PCngm9ufh/bf E3xt4ss/h1/bPhjTPEcPgS38O2/ib7b4gi1LULv7/oA/GH/gmL4s8K+Av2wv+Czf7EWh+Jvj B4rufgX+2/4W/apsbj4j6zp2u+FfCfhX/go98DPBH7RmqfDr4YzWdzZyaD4f0L9oOz/aL8St 4Rh8J6Rp2l6d418P6zceIvHPjbxJ461xf2er8wP2ZvEXjv4if8FP/wDgqP4s1D4df8Iv8Mvg /wDD/wD4J9/sdeEfHn/CXaPrf/Cz/Hfw/wDAHxz/AGw/iLef8IvBBY+IPBX/AAiXh/8Ab5+F vhn7Pqdtqej699n/ALZ0LxPe3sviLwx4N/T+gAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD8wPGsHgT4P/t2XvwU8f+Ef+Ew+Av8AwVp+H/j+DxH4 Z8R/DrWPGnwsuP2sf2efg74c8J+NfCPj/Wbzw74w8L33/DXf7DHh2y0+z+HXjXVfh98NtE8O f8E+fGt14c8O+PfHXx38f3Nl+QPh/wD4NR/2Nvg//wAFJ/gV+1z8EdL+H+r/ALIvh3/hJdN+ Mn7BX7QnhK++OPgS4/tf4C/FvwLZeMvAfjH4oal8QL3xR5XxN1P4TeL1+GnxV0jV/wCxNYi8 d+PfDnxYsIdI8A/Cmy/o+/aQ/Zo+Fn7U3gTR/BXxO0nde+CfiB4I+Mvwh8f6ZYeHLnx38D/j t8LdYj8R/Cv43fC288V6D4o8P6Z8QPh/4giW909PEHhzxJ4O8UaPc674A+I/hLxt8MvF/jPw V4h/KDxN/wAFtPCv7Kv7XFt/wTw/b1+FHiDwn+1h4v8AD/hPWP2XfFHwBj07xt8Gv26IPHut 6N8NfhPZfD2w8R+KdP8AEn7L3xg+M3xkt/iF4Mh+EH7Revt8Gvg9P4JuJ/Ff7aHi/wAHap4b +I3iMA+QPjD4T/4N4vAX/BST4HeBfEfhn/gjD4L8E+C/2YP2+vCfxy8Ha3o37D/hzwr4T+Pv hz48/wDBP7R/h94Z+LHh6+trPSNB+MGhaRZ/H/S/BujeL7O18aaXp1r8YbHRLaC2g8axL+z3 2H/gnH/wTQ/0LwB8Iv2f/wBmbxb8d/8AkE/Cn9lz9nTS4/jt+0T/AMKw/e3/APwg37P/AOzR 8O9X+Nvx+/4VHpnjy88R+Jv+EK8AeNf+FV+Dte8Q+NfEf/COeEjr2tRfzg+Lv+Dd/wCLv7UH /Bavw7/wUd8WaF/wwb8EvEfkftTto3wG+JPwT+Kfxs8H/tY/CvXvh1c/DF/GfhnxB8BbL4Jf DL4gfE3U722+NvxfsfDNp+3z8NtV+Lvws+O+maz8cPEemfGj4ceLIf6vvgX+y58Cf2cP+Epv fhP4G/s7xb4+/sT/AIWX8VvGHibxj8V/jt8Wf+EV/teLwb/wuL9oD4seIfG/xt+L3/CB6Zrm peHPh9/wsvx/4q/4QDwc9r4K8G/2H4S07TdFtAD5fuf2rf22viL4q0bTv2cv+CcPiC3+Hd94 f8TeJpPjR+29+0b4H/ZL8K6/p0Oo+E4Ph3beB/hd8KPBf7Y/7UemeIPiBoeteIPFeo+E/wBo z9nz9mvxV8M9O8Mr4d+IGjaP8RNSuPBOj+f/ABr/AOCl3ir9hrwrp/j/AP4KRfsweIPgX8G7 nxBa6V4h/al/Zi8caj+2X+zB8KINd07VU8HWvxouovhj8C/2sfBviDxR4x0VfA0GoaD+x941 +DVj4g8efB/Srn41nxJ451jw34L+/wD4/fH74NfstfBr4hftB/tB/ELw/wDCv4N/Cvw/N4m8 deOvE006adpGnJPb2NnbW1nY295q+u+INd1e807w74T8J+HtO1bxV4y8Vato3hTwpo2s+JNZ 0vS7v8wfgXc+Kv8Agr7p37Pf7X/j7RvjB8A/2D/D3iD4L/tN/sofs7al4m1H4afGX9oP4mfD zxV431rRvil+3J4N03wndW0Hwf8ABfjfw58G/jf+xr8M/g98e/FPw9+J8Gn6V8dPjneeObDX vhx8L/hcAev/APBJnwB9m/Zx8b/tRz+NfiB41vf+Ckf7QHxL/wCCilj/AMLF8R/8JHrHgn4W ftG2vhj/AIZf+FcG+yWbw3/wq79kXwh8AfA3iLwPD4h8deHPBPjvQ/F3hn4e+N9c+GWmeC/s 36f1/ND+yt+1b8Pf2CP2oPiL+zb8HvgJ8YPFn/BPz9sjxB4u/am/4J0XHwb0n4ZzeFdG07wF 4f8ADsn/AAUMsf2aPhR4z/ayf4yfFT9mDRvEmreE/wBqr9nr4c/sofsxp4q+MOnfFX9onxn+ yH8EPjb8A9L+GHxE8Yf0feE/FnhXx74V8M+OvAvibw/408E+NPD+jeLPB3jHwnrOneI/Cviz wr4j0621jw94m8M+IdHubzSNe8P67pF5Z6po2s6XeXWnapp11bX1jcz208UrAHQUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFc/4s8WeFfAXhXxN468deJvD/gv wT4L8P6z4s8Y+MfFms6d4c8K+E/CvhzTrnWPEPibxN4h1i5s9I0Hw/oWkWd5qms6zql5a6dp enWtzfX1zBbQSyr/ADRf8FOP+C9njH4EfEX4AeFv+Cddj+z/APtNeEviH+z/AP8ABR34xeNf ih8RPD/x2HwJ1/8A4Y4/ZYuPj34cuv2dP2mvAFlH8Evjv/wjmp6B430j4u+D/hXrfxH8vxj4 bsvgX44+IX7NHi3W73x54cAP6fa+IPFn7d/w9fxV4m+H37Ofw0+MH7b3xE8BeINZ8MfE7w5+ ytZ/DPVPCvwr8QeFtRudE8aeD/iL8f8A41fFD4J/sueGvjB4H1w6HY+Lv2bLj45SftQaNp3i zw741m+CzfDuTVfF+k/zQ+N/2+v2jvjn8E/2Y/iv8aT/AMNBaZ+1Z+0B/wAE1/2Uo/2ZZ/iP dfsxfsWJ+1j+2/8ACL9mf9q/Uvhf4u+Fvwk+GnjP9pL4hfsgP+wn8c/E/gX4i+MP2k/2zf2r /ht8Qv2nde8RQ+MP+CYfiz4JWXgK38GfYH7VP/BbbWP2HNY/4JS/Dv4Y/sw/D/SPhL+0R8QP 25/2NPH3wN8EeG/Hfia6+Hfxs/Yk8d+Hf2QPhf8AD79m+/8Ag34a/tr/AIZ//wCGmt2jx634 f/ZP+IPxd179nG00fVvhx+y1pvxaey+C1yAfr9/woL9qf9oj/Sv2sfjV/wAKU+H83/NsP7DH xH+Ivg/7X5f7v/i6P7dv9jfCT9prxx9n1rRPDnxC8E/8M0+D/wBg/wD4Rn+1fF3wd+Mn/DUH w/uv7U1L2DRv2Iv2L/Dnwa8Wfs5+Hv2RP2YNC/Z88e+ILbxZ46+BOjfAL4U6X8GvGniqzn8M 3Vn4m8WfDCx8JweCfEfiC1ufBfg64ttZ1jQ7zUYJ/CfhmaK5WTQdLa18f/aP/bC8d/DX9iz4 XftWfDb4HfECbxb8SviB+wTplt+zx8UvDWj+DvjZYaP+1l+07+zz8I/Fnwt13wv4m+I/gPwl 4I/aA0Pwl8Xtc8P6Zp/jb4m6P4E8HfF2w08eOdduvCWl6yLr4A/Zw/4LYeI/iBo/xR8V/Gv9 mv8A4Vz4M+F37X/7e37F/iaef4r/AAs8IfEnwv8AHb9kjwJ+0N+1ro3gjxd4a8WeO739mvRP h/b/ALFfwf0rSviL+0rqH7a2n+Dov2sW8RaBa/Dvw3+zkbb486YAfQHj/wD4Iufs/wCr/Czw V8JPgX+1N/wU/wD2N/D/AMP/APhHNM8LXP7NH/BS79r+L+yPAnhTw5e+GdE+Fuk+E/jp8T/j j8MvDvw/sLKXSJLDT/C3gLQtY0j/AIRfQdN0TXdM8PjV9G1fv/H/APwTf+Ivxb/4QrT/AIpf 8FUP+Cn/AIg8JeD/AIgeHPH954R8AfEf9lj9l/8A4Tj/AIR/7bBceCvGvxF/Y6/ZE/Z3+Nt3 8P8AxNpmpahpniPw5oXxS8P/AGjzrPXdMvdK8W+H/DHiLRPmDw7/AMFNf2uPE3ir9i7x7rXw O/Zg+FH7PnxB/Yg/bn/bL/bB8Gan8ftb8V/H34X6j+yJqPgLwPrv7Ovh7xb8T/Cf7K/wJ+Ef xg+FXxJ+L/wv8L/tBn9onXtA8K+B/Gmn/tDfDLxlrfwmk+Ael/EP4w+/6x/wUA+Mp/4JwfBr 9tSw+AXh+x+MnxF+MH7JHgDxR+y94Z8fwfEzxB4P1H43/tv/AAi/Zi+JvwIufFXj22/Zc0jQ /wBp/wCH2keN/E/gHxZ4W+JX/CvfCvwV/ag0DWfAPxG1TWPDfgTXtW1kA+oPhb+wj+zP8JvH ehfFLTfC/wAQPiR8TfB/9p/8K6+Iv7Svx/8A2hP2u/Hfwi/4SDR9Q8O+Lv8AhSPi79qn4p/G TxB8EP8AhPvD+pSaF8Sf+FSah4M/4WVo9joOmePf+EisvDXh2DS/n/8A4LM+P/8AhWH/AATY /aQ8a6r4K+IHxI+GWmf8Kfs/2kvAHwt8Of8ACUeO/GX7G3iD49fC7w5+214c0KzW90ibSP7X /ZF1f412Wp+NbXxH4Mvvh3o8uoeP9P8AH/w/vfDVv410H4A+IP8AwXe8d/Bb9l39oj9pD4hf slf2j/wyp/wuHxF8efAV58UNH+Hfjvwho/ir/gol+2V+wD+xZ8OvDGl+F7X9on4f/ET4gX/x A/ZUm0/9sXxdb/GDwr4E+F2j39x8UfgDB+0T/aNp8ItJ5/8Aaw/4KXeKvjx/wTH/AOCsPw5+ I37MHiDw38dvDfwf+JP7L/hr4Y/s4+ONR/adg+Ivir9p39qT9q3/AIJN/CB/CGp678Mf2ffG Op+INT/ax/Z9+JV/q/guw+Gt/qMXwav/AIa+J/DF94u+JPi7X/g/4GAP2f8AjV4A/wCGkdH/ AGQ/jp8BPGvw/wDFF78H/wBoD4UftL/CvxTN4j/tv4RfEL4WfEDwJ42+Bfxe1a01vwZZa7N4 s/tn9kX9or4z+KfgLf8AhzV9M8Oaj8bLf4P634n169+GUXivSNb+QP8Agl98RfAmp/FP9vrw L8NoPiBB8MvHn7QEn7dPwLj8UeItY8U+Dpfgn+1V4j+JXwk1fxn8L9S1vxd4qhg+H/7Rf7XX 7Hv7X37Zvwzi8BTP8IvFHwJ/ae+DHxX8C31pe/EzxT4C+H/w/wDtl+L/ANm4/s1fs6/tefs7 /s1ftP8Ax01f9u3w+f2oLT9ibwh8bP26dY8F+OPhJ4o+CGt/tNfEhPiV/wAE7P2VPi74u+BP iLw/+0f8Sdb+F/7Lf7R3jTV/hF4y/Z48NfH39t3SPjz+1LY/HnSNa8WfD742eQftW/8ABazw J+x1/wAFP7fxZ8P/AIRf8NMfDL9tb4f/ALO/7DPw/wDHnw98faxq2fjZ8CvAF/8Ath/Dfxl4 P8L/AAh+FXx38QfGT9n/AONfh/8A4K+/sw+GbXxj8K7bxH8XdL/4Rb4xaz8O/gH8ab3S/hh4 Y+LAB/V7RX5gfEL/AIKTf8It8Xf+CePwL0b9nn4gWHxN/wCCl37P/wC0v8UPgp4W+Nmp/wDC mtY+FPxT+AnwT+G3x00r4MftO6Ja+HfiJ4g+GH9veH/GXibwt8QvFHhPSPid4j+FPjvwjaaJ bfDP4hWWvahq/hb6A/4J+fHT4p/tPfsO/smftIfGvwt8P/BnxN+Pf7P/AMLvjF4m8O/C3W/E eveBLT/hZHhLTPF2jXWhT+LNI0jxBpH9r+H9X0rWNT8H6hJ4l/4QPWL/AFDwRa/EL4nWXh+2 +IvikA+v6KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACivAPjp+1V+zj+zR/wi1t8dfjR8 P/hv4g+IH9twfC3wFrev2svxT+M2seH/AOyI9Q8I/Av4SaYb/wCJvxx+IEt74i8NaNpHw6+E nhPxn478Q+I/FHhbwz4f8O6n4g8S6FpuofP/APwn/wC2T+0z+4+D/gr/AIYu+CWo/J/wvD4+ +HLHxV+1P418OXnyf2x8Ff2WPtsnhL4Ef8JH4S17TPF3w4+J/wC2J4i1r4p/DD4i+FdZ+HX7 Qf8AwTF1HTLj7cQD6/8Ail8WPhZ8DvAmu/FL41/Ev4f/AAf+GXhf+zP+Em+IvxS8ZeHPh/4E 8O/23rGn+HdG/t3xd4s1LSPD+kf2v4g1fStC0z+0NQt/t+sanp+mWvm3t7bQS/IH/DT/AO0d 8b/+JV+yr+yh8QPCnh/WONM/ac/bW0a6/Z/+Fmm6Of8AiR67r+gfsw6hqVt+3P42+IHgnxRc m60r4L/Gj4Kfsb+BPjJ4c8JeK9Q0D9qrwL4f134W+NPH3oHwt/Yp+Fngbx3oXxp+I2v/ABA/ ai/aN8Nf2n/wjP7Q/wC0rqvhzxn478Bf2zo+oeFNZ/4Uj4L8J+FPAfwF/Zh/4SnwLd2Pgf4k /wDDLPwc+Cn/AAurR/D+g6r8b/8AhZHjO1ufFN59f0AfEHhP9iHwrrPirwz8V/2rfHHiD9sP 4yeFfEGjeN/B118UdO07S/gF8FfHGh6jbeJPD2u/s3/staO0vwp+HHiD4ceKZfEcnwf+O/j2 3+Mn7bXg/wAF+J9Q+Hfin9rv4h+G44kP0/4u+E/ws+IGseHfEXj34afD/wAbeIPCHkf8Inrv i7wb4c8Sax4X+zeO/h18Urb/AIR3U9Z029vdE+z/ABN+D/wk+IsH9mz23leO/hd8OvF0e3xB 4J8M6hpnoFFAHzB4m/Yi/Yv8aadbaP4x/ZE/Zg8WaRZ/B/wn+z1Z6X4m+AXwp17TrX4BeAvF WjeOvAvwOtrHVPCd1bQfB/wX428OeHvGPhP4aRRL4L8OeKtC0bxDo+i2er6XY3kHQeIv2Tv2 WPF+j/Drw74s/Zp/Z/8AFHh/4P8Aw/8AF3wn+EmheIvg38Otb0f4XfCz4geBIPhb49+Gnw60 zUvDlzZeCfh/42+GVtbfDrxd4N8MwaZ4c8SeBLeDwjrOm3vh+KPT19/ooA8/g+E/wstvAnhH 4W23w0+H9v8ADL4f/wDCuv8AhAvh1B4N8OReBPBP/Cn9Y8O+IvhJ/wAIj4Rj01fD/hv/AIVd 4g8IeE9d+HX9jafZf8ITrHhfw7qfhn+zL3RNNntuAn/ZO/ZYudY8XeIrn9mn9n+48QfED4f/ ABF+E/j3XZ/g38OpdY8bfCz4weO/EXxS+Lfw08XanJ4ca98SfD/4o/E3xf4s+IvxF8G6zPe+ HPG3jvxR4i8XeJtN1PxBrepahc+/0UAeAeIv2Tv2WPF+j/Drw74s/Zp/Z/8AFHh/4P8Aw/8A F3wn+EmheIvg38Otb0f4XfCz4geBIPhb49+Gnw60zUvDlzZeCfh/42+GVtbfDrxd4N8MwaZ4 c8SeBLeDwjrOm3vh+KPT17+D4T/Cy28CeEfhbbfDT4f2/wAMvh//AMK6/wCEC+HUHg3w5F4E 8E/8Kf1jw74i+En/AAiPhGPTV8P+G/8AhV3iDwh4T134df2Np9l/whOseF/Dup+Gf7MvdE02 e29AooA8A8U/snfsseOP7I/4TX9mn9n/AMYf8I//AML0/sH/AISn4N/DrxB/Yn/DUH9t/wDD S/8AZH9reHLv+zf+GiP+Em8R/wDC9Psfk/8AC2/+Eg1v/hP/APhIP7Vv/tG+v7PXwCTTviPo 6fA74PrpHxj8P+IPCfxd0tfhp4LXTvip4V8WeKvid468VeGfiPYjRRbeOPD/AIl8bfGz4zeM fEGjeJ4tU07WfFXxc+J3iHUba51fx74qvNW9gooA/OD/AIJdeE/Ctr+xL+yLo+qeGfD998Vv 2Qfg/wCLf+CfuuePW0bTrnUYPFX7Jfjiy/ZS/aLg+HHim4tl8SRfB/4nfGT9lCx8Y+H47yLw zqPjTwr4b+GPiHx14M8N+KdHh8OeHPkD9p//AIJ7/s1aF/wUH/4Ju/HLxB4K8P8AxD0jxR4g +LX/AAT38BfADxT8NfghovwC+Bf7NWvf8E5f2tfF+veCvAHhz4ZfCr4e+NvHfh++tvghqPgr S/hr+0p8Qfj58EPA3gv46fHex+G/wq8G6v4p8L634K+3/wBgX/ikv+G1PgF/yEP+Gfv2/wD9 o7/irP8Aj0/4S3/hsD/hDf8Agpd/yAv9J/sH/hXf/Dcf/Clf+QzrX/CW/wDCr/8AhY//ABTP /Ca/8IH4SP8Agon/AMU/8Ov2cvixpH+ifED4Sft//sD/APCvdf8A+Pj/AIR//hoj9qf4afsU /GL/AIlV152i6r/wmH7Mv7UHx0+Gn/E703Uv+Ef/AOE4/wCEy8Lf2J8QPDPg/wAV+HwD6ftf 2evgFY6j8FNYsfgd8H7PV/2a/D+q+E/2dNUtfhp4Lt9R+APhXXfCun+Bdc8M/BS+h0VLn4V+ H9Z8E6Tpfg7VdG8Cy6Dp2o+FdN0/w9eW02kWdvZx9B8LfhP8LPgd4E0L4W/BT4afD/4P/DLw v/af/CM/Dr4W+DfDnw/8CeHf7b1jUPEWs/2F4R8J6bpHh/SP7X8Qavquu6n/AGfp9v8Ab9Y1 PUNTuvNvb25nl9AooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAor4g8Wft9/BqDxV4m+G/wAD/C/x g/bC+K3hPxBrPgzXvBP7K3w+n8e+FfDnxC8J6jc2nj34V/EX9pzxRqPgT9i/4IfGD4e6dY3v iDxd8Ifj5+0p8LPiZa6c3h3TtO8Kap4p+IXwy8O+NOf/AOFBftT/ALRH+lftY/Gr/hSnw/m/ 5th/YY+I/wARfB/2vy/3f/F0f27f7G+En7TXjj7PrWieHPiF4J/4Zp8H/sH/APCM/wBq+Lvg 78ZP+GoPh/df2pqQB7B8a/2vPg18E/FWn/Cy6vfEHxP/AGg/EPh+18T+Dv2Y/gpoM/xL+Pvi Xw/q2o6r4d8PeMNQ8E6PKlt8K/g/rPjbSW+H11+0n8dta+FP7L/gfxpqGlaT8T/jT4Gjv4rs eP8A9n/8FBP2gP8ARtd1P4f/APBP74ZXf/Ewguvhprvhj9p79snWNH1L/ia+HdM1LUPiL8LW /ZF/Zk+IHhGbTtM0b4saFp/hP/go14E8d2Pinxl4Z+FvxS8B3vhDwj8a/Fv0/wDBT4A/Br9n TwrqHg74K/D3w/4C0jXvEF14z8Y3mmwz3nir4k/ELVNO0rS/EPxU+LfjrWLjUvG3xe+MHjG2 0PSpfHvxe+J3iHxZ8TPH+o2ceseNPFeu6u0t9J7BQB4B8C/2XPgT+zh/wlN78J/A39neLfH3 9if8LL+K3jDxN4x+K/x2+LP/AAiv9rxeDf8AhcX7QHxY8Q+N/jb8Xv8AhA9M1zUvDnw+/wCF l+P/ABV/wgHg57XwV4N/sPwlp2m6Lae/0UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfAHw I/4on/goJ/wUC+Fulf6R4f8AiB8P/wBin9tbWbzUP3usW3xT+MHhj42/sdeJtA0y4tvsllD8 P7H4Zf8ABO34Ka7oWlXWn3viO28d+KPilqeoeK9T8P634T8MeCT/AIKt/wCjf8Eyv2/vEVt/ o/iD4f8A7IH7QfxY8B67B+61jwT8U/g/8MPEvxS+EnxL8I6nHtvfDfxA+F3xN8IeE/iL8OvG WjT2XiPwT478L+HfF3hnUtM8QaJpuoWx4j/4pL/gqb8G/wDhHv8AiX/8NAfsAftLf8Ld/wCX v/hLf+GP/wBor9k7/hnT/j++0/2D/wAK7/4bj/aj/wCRZ/sX/hLf+Fof8Vz/AMJN/wAIV8O/ +ES+/wCgAor4A/4JSf6N/wAEyv2AfDtz/o/iD4f/ALIH7Pnwn8eaFP8AutY8E/FP4P8Aww8N /C34t/DTxdpkm298N/ED4XfE3wh4s+HXxF8G6zBZeI/BPjvwv4i8I+JtN0zxBompafbff9AB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFef/ABS+LHws+B3gTXfil8a/iX8P/g/8MvC/9mf8JN8Rfil4y8OfD/wJ4d/t vWNP8O6N/bvi7xZqWkeH9I/tfxBq+laFpn9oahb/AG/WNT0/TLXzb29toJQD0CivgD/hp/8A aO+N/wDxKv2Vf2UPiB4U8P6xxpn7Tn7a2jXX7P8A8LNN0c/8SPXdf0D9mHUNStv25/G3xA8E +KLk3WlfBf40fBT9jfwJ8ZPDnhLxXqGgftVeBfD+u/C3xp4+P+Henws+K/8AxPf259T/AOG9 /Ft1/pf/AAjHx98K+HL/APZY8A30/wDpn2f4K/sdeRqPwS8K/wDCK6nqPi7T/hx8Xvijpnxu /bJ0P4deMdZ+Fvjb9rL4leEn+zuAH/Dc/wDwuj/iW/sC/C7/AIbG83/mvP8Awm3/AAqf9hPS tn7/AP5O1/4RH4jf8Lo+3f2V4y8G/wDGFfwm/a4/4Vz8YvDH/CtP2jv+FCf2l/wktif8Md/F P40/u/25/wBpD/he/hKH/RP+Ge/gF8PPEf7Jv7LHi+xj+X7R8avAn/C4/jf8bfjz/b+mar4u 8EfEf4Q/FH9pDXv2Nvij8OtY0bR/G37JuqeLfDn/AAnmrff9FAHP+E/CfhXwF4V8M+BfAvhn w/4L8E+C/D+jeE/B3g7wno2neHPCvhPwr4c0620fw94Z8M+HtHtrPSNB8P6FpFnZ6Xo2jaXZ 2unaXp1rbWNjbQW0EUS9BRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHwB+1 x/xKP2ov+CWHiLSv+JZ4g1v9r/4x/CfWdd0//QtY1f4WeKP+Cdv7bXxS8TfDTU9TtvKvb/4f +Ivib8Dvgp8Rdd8G3U8vhzV/Hfwf+Fvi7UNNuPEHw/8ACeoaR9/18Af8FM/9G/Zd0fxFc/6P 4f8Ah/8Atf8A/BOL4sePNdn/AHWj+CfhZ8H/APgol+yz8Uvi38S/F2pybbLw38P/AIXfDLwh 4s+IvxF8ZazPZeHPBPgTwv4i8XeJtS0zw/ompahbff8AQB8Af8E7P+Kf+HX7Rvwn1f8A0T4g fCT9v/8Ab4/4WFoH/Hx/wj//AA0R+1P8S/21vg7/AMTW187RdV/4TD9mX9qD4F/Ev/iSalqX /CP/APCcf8Ib4p/sT4geGfGHhTw/9/18Afsz/wDFE/tp/wDBSj4W6r/pHiD4gfED9mL9tbRr zT/3uj23ws+MH7MXgj9jrwzoGp3Fz9kvYfiBY/E3/gnb8a9d13SrXT73w5beBPFHwt1PT/Fe p+INb8WeGPBP3/QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUV8wfGv9rz4NfBPxVp/wsur3xB8T/2g/EPh+18T+Dv2Y/gpoM/xL+Pv iXw/q2o6r4d8PeMNQ8E6PKlt8K/g/rPjbSW+H11+0n8dta+FP7L/AIH8aahpWk/E/wCNPgaO /iuwAfT9eAfHT9qr9nH9mj/hFrb46/Gj4f8Aw38QfED+24Phb4C1vX7WX4p/GbWPD/8AZEeo eEfgX8JNMN/8Tfjj8QJb3xF4a0bSPh18JPCfjPx34h8R+KPC3hnw/wCHdT8QeJdC03UPn/8A s/8A4KCftAf6Nrup/D//AIJ/fDK7/wCJhBdfDTXfDH7T37ZOsaPqX/E18O6ZqWofEX4Wt+yL +zJ8QPCM2naZo3xY0LT/AAn/AMFGvAnjux8U+MvDPwt+KXgO98IeEfjX4t+gPgX+y58Cf2cP +EpvfhP4G/s7xb4+/sT/AIWX8VvGHibxj8V/jt8Wf+EV/teLwb/wuL9oD4seIfG/xt+L3/CB 6ZrmpeHPh9/wsvx/4q/4QDwc9r4K8G/2H4S07TdFtAD5/wD+E/8A2yf2mf3Hwf8ABX/DF3wS 1H5P+F4fH3w5Y+Kv2p/Gvhy8+T+2Pgr+yx9tk8JfAj/hI/CWvaZ4u+HHxP8A2xPEWtfFP4Yf EXwrrPw6/aD/AOCYuo6Zcfbj6B8Lf2KfhZ4G8d6F8afiNr/xA/ai/aN8Nf2n/wAIz+0P+0rq vhzxn478Bf2zo+oeFNZ/4Uj4L8J+FPAfwF/Zh/4SnwLd2Pgf4k/8Ms/Bz4Kf8Lq0fw/oOq/G /wD4WR4ztbnxTefX9FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAfIH/BQn4W+O/jj+wL+3D8FPhboX/CUfE34wfsgftLfC34deGf7T0fRP+Ei8d/ED4L+ NfCfhHQv7Z8RahpHh/SP7X8Qavp+n/2nruq6Zo9h9o+1anqFlZRT3MXv/wAJ/il4E+OPws+G nxr+Fuu/8JR8MvjB8P8Awb8Uvh14m/szWNE/4SLwJ8QPDmm+LPCOu/2N4i0/SPEGkf2v4f1f T9Q/szXdK0zWLD7R9l1PT7K9intovQK+AP8Aglx/xJv2E/gZ8Jv+Pn/hlf8A4Wb+wx/b/wDq f+E7/wCGBPjF8Qf2Kf8AhaP9lfvf+EY/4Wx/woT/AIWX/wAIT/aXiH/hBP8AhK/+EN/4S7xl /YX/AAlesAB/yT//AIKm/wDQW/4a2/YA/wCvD/hX/wDw7v8A2iv+33/hK/8Ahb//AA9B/wCp b/4V/wD8KO/5nb/hZf8Axb/7/r4A/aY/4on9tP8A4Jr/ABS0r/SPEHxA+IH7Tv7FOs2eofvd HtvhZ8YP2YvG/wC2L4m1/TLe2+yXsPxAsfib/wAE7fgpoWhardahe+HLbwJ4o+KWmah4U1Px BrfhPxP4J+/6ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAoor4A/wCG5/8AhdH/ABLf2Bfhd/w2N5v/ADXn/hNv+FT/ALCelbP3/wDydr/wiPxG/wCF 0fbv7K8ZeDf+MK/hN+1x/wAK5+MXhj/hWn7R3/ChP7S/4SWxAPv+viDxZ/wUC+AUXirxN8Lv gRP4g/bP+O3g7xBrPhPxj8DP2RJPBfxQ8VfDjxV4a1G5sfEPhn47/EHWPGfg39nz9lrxBaR6 R4vn0LRv2qvjR8EdR+I+o+AfG/gn4UW3jz4k6DL4Kl5//hk34p/tBf8AEz/bn+L3/CY+Er/9 /wD8MdfAK48R/DX9lizsbr/SP+EV+NXif7XZ/G39tH7PpmteLvhb8R9M+KOu/DX9jb9oz4dX Wjah42/4J6eDvFth9sX7f8J+E/CvgLwr4Z8C+BfDPh/wX4J8F+H9G8J+DvB3hPRtO8OeFfCf hXw5p1to/h7wz4Z8PaPbWekaD4f0LSLOz0vRtG0uztdO0vTrW2sbG2gtoIolAPiD/hR37ZPx 5/4mH7RH7Rv/AAzV4Suv9Duv2dP2GNSsb/8AtXw5e/8AEr8YeHPij+2h8YvhRp3xt8Vf8JVp mnW+p+CfGv7KXwt/4J/fFP4If8Jj4u0Kw8f/ABK8W+H/AIffGbQPp/4KfAH4Nfs6eFdQ8HfB X4e+H/AWka94guvGfjG802Ge88VfEn4happ2laX4h+Knxb8daxcal42+L3xg8Y22h6VL49+L 3xO8Q+LPiZ4/1Gzj1jxp4r13V2lvpPYKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAr4A/YR/4pXxH+3x8C9P/AH3hL4Eft/8AxZ/4RHUb 3954j1H/AIay+FnwP/4KL/EX/hJLuD7Ppl5/Yvxt/bR+KXhbwV/ZmkaP/Z3ws0HwBomu/wDC R+LdL8ReOPFX3/XwB8GP+KV/4KO/t3+ANB/0Dwl4x/Z//YN/aj8SaT/x9f2j8dviVqn7X37N HjXxz9vvftGp2f8AbXwS/Yu/Zo8Ff8IzYXtr4O07/hWv/CR6T4esPFvjHx/r3ioAP+Cif/FP /Dr9nL4saR/onxA+En7f/wCwP/wr3X/+Pj/hH/8Ahoj9qf4afsU/GL/iVXXnaLqv/CYfsy/t QfHT4af8TvTdS/4R/wD4Tj/hMvC39ifEDwz4P8V+H/v+vgD/AIKt/wCjf8Eyv2/vEVt/o/iD 4f8A7IH7QfxY8B67B+61jwT8U/g/8MPEvxS+EnxL8I6nHtvfDfxA+F3xN8IeE/iL8OvGWjT2 XiPwT478L+HfF3hnUtM8QaJpuoW33/QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA V8gftK/HT4p+EPHfwR/Z7/Z28LfD/wAU/Hr4+f8ACydeXU/ilrfiPSPAnwR+BPwp0fQdP+J3 7Smu6F4f0g3vxo/4V18Tfin+z74D0z9nPQfHfwp8Y/FvWPi/p7WfxP8Ahp4F8LfEf4peAfr+ vgD4jf8AKU39jf8A7MA/4KWf+tFf8EnaAD/hXP8AwVN/6PI/YA/8Vp/tFf8A02Kj/hXP/BU3 /o8j9gD/AMVp/tFf/TYq+/6KAPgD/hXP/BU3/o8j9gD/AMVp/tFf/TYq5/Uviz+2h+zF4q+E l9+1F4j/AGYPjt8Cfix8YPAXwU8W/Fb4KfCr4rfsv+Kv2c/FXxW1GT4efA/UNQ+FfjD43fti yftEeH/jd+0H4r+E/wADLq68N+NfgtqPwM1HxnpXxB8R6V8RfhtdeO/Enwd/R+vzJ/4K9axd +HP2KT4ksfGvgf4a3Xhr9r//AIJpeI4viT8TtMl1r4Z/Dr+wP+ClH7JWsP4/+I+kw+M/hxJq Xw/8Fx2T+JvGtmvxD8BfaPDOl6pGfGvhVWOvWAB97fFL4sfCz4HeBNd+KXxr+Jfw/wDg/wDD Lwv/AGZ/wk3xF+KXjLw58P8AwJ4d/tvWNP8ADujf274u8WalpHh/SP7X8QavpWhaZ/aGoW/2 /WNT0/TLXzb29toJfkD/AIar+Nnx5/4kf7HX7OfxAsLKf/Qdd/aJ/bW+GPxd/ZV+Fnw8upf9 D1OLQP2ffil4T8CftdftAfEDwlDrHhjxzpXgyz+G3wO/Zx+K3hxPFfgm3/bp+GfxN8O6hoNn 8i/sNfG7/gl1+0R+1Rr+gfC79qTxJ/wUB/bj+COh+O/E8vxw+N+j+JPGOr/D/wAN6Pqtl8G/ G3iH9nHVNI+Enwy/Y6+C2h+J9J8ZeE/h9401b9iXwX8NLD9o7wxY+GvGfxLuPi7qlpe+Pbn9 uaAPgD/h334E+KP/ABOf21PiD8QP20/EGp/vPEXw/wDiXrmseF/2NmtZf+JrB4I039hTwjrd t+zl43+H/gnxnc6j4s+E+sftR+Gf2nf2jvCF9F4NufE37SHxA8QfDD4deJPDf3/RRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAV8AeNf+JP/wAFTf2af7I/4lX/AAsb9gD9uH/hYP8AZv8AoP8Awnf/AApf9or/AIJ7f8Kd /wCEy+y+V/wk/wDwqf8A4X38dP8AhWn9t/bv+EE/4XR8Wf8AhFv7K/4WN4w/tj7/AK+AP21f +Jd8aP8AgmD4w1D/AEDwl4O/b/1L/hLvFN7/AKL4c8K/8LK/YF/bt+Bfw6/4STW59mmaH/wn 3xt+K/wt+Dvgr+07q1/4Sr4p/ErwB8PdC+3+LfGPh3SNRAPv+vgD/glJ/o3/AATK/YB8O3P+ j+IPh/8Asgfs+fCfx5oU/wC61jwT8U/g/wDDDw38Lfi38NPF2mSbb3w38QPhd8TfCHiz4dfE XwbrMFl4j8E+O/C/iLwj4m03TPEGialp9t9/18Af8E7P+Kf+HX7Rvwn1f/RPiB8JP2//ANvj /hYWgf8AHx/wj/8Aw0R+1P8AEv8AbW+Dv/E1tfO0XVf+Ew/Zl/ag+BfxL/4kmpal/wAI/wD8 Jx/whvin+xPiB4Z8YeFPD4B9/wBFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHxBP+y/8A AL4/63+1D4U/aMf4P/tseCdQ/af8I/EfS/gf8a/Bfgv4zeFf2TPFWk/sj/s/eBLH4Y6f4S8d X3j3SPCfiDVNIXXP2g7Vrfw74C1FdO/ah1XUYfD9xbeLLzxh429/1n9nr4BeI/jL4T/aM8Q/ A74P67+0H4C8P3PhPwL8dtZ+GngvVPjL4L8K3kHia1vPDPhP4n32iz+NvDnh+6tvGnjG3udG 0fXLPTp4PFniaGW2aPXtUW64D4Baz8GtU+K37btj8MPCfiDw5428OftP+E9G/aM1jWbmefTv Hvxln/Yv/ZE8Q6H4s8JxTeJtdjs/D9n+z5r3wJ8C3Nta6X4LgbxV4L8TXjeGbq5urjxj4s+n 6APANE/ZO/ZY8M/8L0/4Rz9mn9n/AMP/APDUH9r/APDS/wDYnwb+HWlf8NEf8JB/wlP9vf8A C9PsHhy3/wCFt/23/wAJx41/tf8A4T//AISD+0v+Ew8U/bPO/wCEg1b7Xz+s/sRfsX+I/g14 T/Zz8Q/sifswa7+z54C8QXPizwL8CdZ+AXwp1T4NeC/FV5P4murzxN4T+GF94Tn8E+HPEF1c +NPGNxc6zo+h2eozz+LPE00ty0mvao119P0UAeP6z+z18AvEfxl8J/tGeIfgd8H9d/aD8BeH 7nwn4F+O2s/DTwXqnxl8F+FbyDxNa3nhnwn8T77RZ/G3hzw/dW3jTxjb3OjaPrlnp08HizxN DLbNHr2qLdYGifsnfsseGf8Ahen/AAjn7NP7P/h//hqD+1/+Gl/7E+Dfw60r/hoj/hIP+Ep/ t7/hen2Dw5b/APC2/wC2/wDhOPGv9r/8J/8A8JB/aX/CYeKftnnf8JBq32v3+igD5g1n9iL9 i/xH8GvCf7OfiH9kT9mDXf2fPAXiC58WeBfgTrPwC+FOqfBrwX4qvJ/E11eeJvCfwwvvCc/g nw54gurnxp4xuLnWdH0Oz1GefxZ4mmluWk17VGuu/wBZ/Z6+AXiP4y+E/wBozxD8Dvg/rv7Q fgLw/c+E/Avx21n4aeC9U+MvgvwreQeJrW88M+E/iffaLP428OeH7q28aeMbe50bR9cs9Ong 8WeJoZbZo9e1Rbr2CigDwDRP2Tv2WPDP/C9P+Ec/Zp/Z/wDD/wDw1B/a/wDw0v8A2J8G/h1p X/DRH/CQf8JT/b3/AAvT7B4ct/8Ahbf9t/8ACceNf7X/AOE//wCEg/tL/hMPFP2zzv8AhINW +1/H/wC0J/w5e+B3gTwH+x1+1Z/w7A+D/wAMvC+34sfDH9lj9oT/AIZS+H/gTw7/AG3rHjux X4l+A/gf8R/7I8P6R/a/iDV/ibZr4y8P+GLf7frGp+O7calLe3viBJf0/r4A/wCCcH/Ex+C/ xq8Yah/p/i3xj+3/AP8ABS3/AIS7xTe/6V4j8Vf8K1/b6/aK+Bfw6/4STW59+p65/wAID8Ev hR8Lfg74K/tO6uv+EV+Fnw18AfD3QvsHhLwd4d0jTgDx/Wf23f8Aghr4j+MvhP8AaM8Q/td/ 8EoNd/aD8BeH7nwn4F+O2s/H39kHVPjL4L8K3kHia1vPDPhP4n33iyfxt4c8P3Vt408Y29zo 2j65Z6dPB4s8TQy2zR69qi3WBon7WP8AwQL8M/8AC9P+Ec/aW/4JAeH/APhqD+1/+Gl/7E+M n7GGlf8ADRH/AAkH/CU/29/wvT7B4jt/+Ft/23/wnHjX+1/+E/8A+Eg/tL/hMPFP2zzv+Eg1 b7X+v1FAH5gfC3/hy9+1v4E0L9jr4Kf8OwP2m/hl8LP7T+LHhn9lj4W/8MpfGjwJ8OdusahY 6z8S9C+B/hP/AISTw/4Q2+IPijqtnqfjLT/DGnY1j4i6hb3WpfbfF1ymofb+s/s9fALxH8Zf Cf7RniH4HfB/Xf2g/AXh+58J+BfjtrPw08F6p8ZfBfhW8g8TWt54Z8J/E++0Wfxt4c8P3Vt4 08Y29zo2j65Z6dPB4s8TQy2zR69qi3XzB/wUf/4l3wX+CvjDT/8AQPFvg79v/wD4Jpf8Ij4p s/8ARfEfhX/hZX7fX7OvwL+Iv/COa3Bs1PQ/+E++CXxX+KXwd8a/2ZdWv/CVfCz4leP/AIe6 79v8JeMfEWkaj9/0AeAaJ+yd+yx4Z/4Xp/wjn7NP7P8A4f8A+GoP7X/4aX/sT4N/DrSv+GiP +Eg/4Sn+3v8Ahen2Dw5b/wDC2/7b/wCE48a/2v8A8J//AMJB/aX/AAmHin7Z53/CQat9r5/W f2Iv2L/Efwa8J/s5+If2RP2YNd/Z88BeILnxZ4F+BOs/AL4U6p8GvBfiq8n8TXV54m8J/DC+ 8Jz+CfDniC6ufGnjG4udZ0fQ7PUZ5/FniaaW5aTXtUa6+n6+AP8Agpn/AKT+y7o/h25/0jw/ 8QP2v/8AgnF8J/HmhT/vdH8bfCz4wf8ABRL9ln4W/Fv4aeLtMk3WXiT4f/FH4ZeL/Fnw6+Iv g3WYL3w5428CeKPEXhHxNpup+H9b1LT7kA8f1n9t3/ghr4j+MvhP9ozxD+13/wAEoNd/aD8B eH7nwn4F+O2s/H39kHVPjL4L8K3kHia1vPDPhP4n33iyfxt4c8P3Vt408Y29zo2j65Z6dPB4 s8TQy2zR69qi3WBon7WP/BAvwz/wvT/hHP2lv+CQHh//AIag/tf/AIaX/sT4yfsYaV/w0R/w kH/CU/29/wAL0+weI7f/AIW3/bf/AAnHjX+1/wDhP/8AhIP7S/4TDxT9s87/AISDVvtf6/UU AfjDrP7Qv/BvF4j+DXhP9nPxD8cf+CMOu/s+eAvEFz4s8C/AnWfiX+w/qnwa8F+KryfxNdXn ibwn8ML7Wp/BPhzxBdXPjTxjcXOs6PodnqM8/izxNNLctJr2qNdff/gbwn+xf+0p4q+G37bv w18M/swfH7xtpPh/XPCfwg/a88DaN8Kfip4q03wrY6j428J+JfDPw2+PugW2vavZ+H7PV9d+ I3hrXNG8L+LI9Ot9R1nxto1/bJc6jrttN9P18AfCj/iUf8FNf23PDulf8Szw/rf7IH/BPD4s azoWn/6Fo+r/ABT8UfE//goh8LfE3xL1PTLbyrK/+IHiL4ZfA74KfDrXfGV1BL4j1fwJ8H/h b4R1DUrjw/8AD/wnp+kAH0Bon7J37LHhn/hen/COfs0/s/8Ah/8A4ag/tf8A4aX/ALE+Dfw6 0r/hoj/hIP8AhKf7e/4Xp9g8OW//AAtv+2/+E48a/wBr/wDCf/8ACQf2l/wmHin7Z53/AAkG rfa+f1n9iL9i/wAR/Brwn+zn4h/ZE/Zg139nzwF4gufFngX4E6z8AvhTqnwa8F+KryfxNdXn ibwn8ML7wnP4J8OeILq58aeMbi51nR9Ds9Rnn8WeJppblpNe1Rrr6fooA+QP2hP+GBfgd478 B/ti/tWf8MgfB/4m+F9vwn+GP7U/7Qn/AApf4f8Ajvw7/bej+O75fhp4D+OHxH/sjxBpH9r+ H9X+Jt4vg3w/4nt/t+j6n47uBpstle+IHl+QNE/ax/4IF+Gf+F6f8I5+0t/wSA8P/wDDUH9r /wDDS/8AYnxk/Yw0r/hoj/hIP+Ep/t7/AIXp9g8R2/8Awtv+2/8AhOPGv9r/APCf/wDCQf2l /wAJh4p+2ed/wkGrfa/f/BX/ABOP+Cpv7S39r/8AE1/4Vz+wB+w9/wAK+/tL/Tv+EE/4XR+0 V/wUJ/4XF/whv2rzf+EY/wCFsf8AChPgX/wsv+xPsP8Awnf/AApf4T/8JT/av/CufB/9j/f9 AH4w6z+0L/wbxeI/g14T/Zz8Q/HH/gjDrv7PngLxBc+LPAvwJ1n4l/sP6p8GvBfiq8n8TXV5 4m8J/DC+1qfwT4c8QXVz408Y3FzrOj6HZ6jPP4s8TTS3LSa9qjXXr+mftY/8EXvjB+0d8Lfi lo37S3/BMD4o/tdW39n/AAn+CnxF0z4yfspeNv2jrf8A4S+613w7pXw0+Fvi618R6n8TYv8A hKL34geJtC0/wb4T1Bf7buvG2u6ZbabczeJNQgvf0/rn/FnhPwr498K+JvAvjrwz4f8AGngn xp4f1nwn4x8HeLNG07xH4V8WeFfEenXOj+IfDPibw9rFteaRr3h/XdIvLzS9Z0bVLO607VNO urmxvrae2nliYA8g0T9k79ljwz/wvT/hHP2af2f/AA//AMNQf2v/AMNL/wBifBv4daV/w0R/ wkH/AAlP9vf8L0+weHLf/hbf9t/8Jx41/tf/AIT/AP4SD+0v+Ew8U/bPO/4SDVvtfP8A7Hun eFdB+CC+FPAv7M3h/wDZD8E+A/jB+0x8OPB3wP8ACfg/TvAPhWz8K/Df9pX4t+BPD3xO8M+E tH8HeA9I0jw/+0HpHh2z/aD0ZdL8OnTrzTvihbajY+IPGNtdxeMNd8//AOCZPizxV49/4Jt/ 8E+fHXjrxN4g8aeNvGn7EH7KHizxj4x8WazqPiPxV4s8VeI/gN4B1jxD4m8TeIdYubzV9e8Q a7q95eaprOs6peXWo6pqN1c319cz3M8sre//AAP0b4y6D4L1qx+O3izw/wCNPG0/xg/aF1nQ 9Y8M20Frp1n8GvEfx9+JfiH9nPwncxW/hnwnG3iDwF+z5qnww8C+LLltLup7zxV4c1m8uvE3 jS5nm8Y66AewV+cH7Rnizwr8If8AgoX+wR8V/if4m8P+BPh349+D/wC2N+xf4Q8VeJtZ07S9 O1z9p/8AaH8ffsUfF34IfCC2FxcrcxeIPid4J/ZQ+O0nhO9ureDw/qXirwno3w7XWF+InxF+ GfhXxj5/8Lv+CosHjj4e/Drxnqf7PfiDUvFP7Sfh/wCBfxN/Y7+CXwb+MPwa8e/GX42fCT9p T4Z/Gz42fC4ePtA+KPib9n/w3+zv8YNE+Df7Nnx1+IfxQ8P/ABF8Wzfs8GDwFe+B/wBnn9qz 9pP4rW/iL4f+GviDxP8A8HCv7IHxi8CXGleFP2Bf2/8A9sP4JfG/7Z8OvCdv8Lf2fv2f/jDo /wC0n4E8fax+2L8PbafQvgDrP7Rdt8bde+H/AMRNM/Yc/azutT8O/ET4KeG9Y0vwJ8OdQ1D4 n+EfCumeKfDMOugH9H1FfzBeO/G3/BEbwD+1+37HGqf8EQ/h+/i2P4geA/A8nxF1D/gn7+wx 4B8CPo/j79oD9nv9lbTfjHpnhH4t+K/h5+0P4k/Z/H7Q/wC0v4A+FmhfGnwt8Ctc8CfFfWND +KWsfAjVfiv4S+FHj3xFofn/AMQPj3/wQu+GHgT4n/Gnxj/wQ9+H+nfs5fDH9n/4Q/tRy/tD wfsP/wDBN2/8CeMvgT+03rHxI8Kfsh+OfCPguy+LU/x6T/hqrx18M9R8D/Drwz4w+DnhHxj8 O9Y17w7qv7TPh74CeDG17xToIB/V7X5if8FQpvhj8Sfh/wDs8/sdeJ5fAfi74j/tV/th/shz eB/gJ4vfw/qEvxk+GP7MP7VPwP8A2qf2r5bjwt4jLaPrHgP4e/s0fCf4ieJfHb6/Gvh/VGl8 NfDO2Or/ABB+J3w78GeLvw9k/aX/AOCQOieJ/BHw68Tf8G5P9r/E3xl8QNY+Huq6H8H/ANgj /gn/APE/wJ8H/Eer/wDBQT9pD/gnd8FPB/x6+N+oeMfAnwf+GHxA+L3xg/Zx1mC0tbnxdq/w sstY16Hw74T+MXxEstIuvFNx+j/wi/ah/Yv/AGYfhn/wUP8Aib+x3+wR8H/gTbfsufsQWP7V 3xa8K/DjwP8ACn9nzxV8Q/iZ8KfiF/wUU+EXjz9mX4nH4R+A9b8LQ+IPgL8Vv2Jfij4CX4pe HfFHxp+Hur6j488Qa98LrjxJ4JtdN8VfEQA89/4J8f8ABvB+zL+xpf8A7S1x451PXPi5rXjr 4p6Vcfs6fGHR/FXiL4R/tC/A74JaJ4bhltNJ8HfG74Mp8MvjL8Hvin4p13xb8Qfh/wDHDxD8 GfinoXhL46fCrQfBNrrPhjwtoviTxp8M4f0h/wCGLvi74J+X4C/8FCP2v/h/4f0H/iYeA/hJ 8WZ/gn+1h8LLbWIv+Jk2mfEvx7+0J8IvF/7c/wAUfh/4k8UNd6j4y0Kb9t7wv47tvDmr6l4H +D/xS+DPh/TPAkfgn4g+CP8AwXm+Enx4/Zu+FX7Rnw8/ZP8A2n/iDbfFTxB4ctn+H/w4vv2e H8VfDHwr8cP26fiz+wX+xzrPxO1D40/HT4EeFj4g/ab+K3wj8SW6+GfhTrnxX074M6jpPiCH 4qeLNG8Ew+DviR499/8A2A/+CrfhX9vTxpp3w58Pfsu/tP8Aw61ez/Zg+AH7Q3jr4vaz4J07 Xv2R9F8VfHj4Bfs1/tDWf7PnhP8AaGsdXsLnxd8YPDfgn9p3wdf3Ph7WPhr4G1HUtE0LxN4o i0yz0iLS21MA9g/42m/D/wD6MA/a2/tb/s4r/gnf/wAK/wDsH/i0H/hb/wDwlf23/qh3/Cv/ APhG/wDmpf8Awm3/ABb8/wCG0fi74J+b49f8E9/2v/h/4f0H/iX+PPi38J4Pgn+1h8LLbWIv +Jaup/DTwF+z38XfF/7c/wAUfh/4k8UNaad4N12H9iHwv47tvDmr6b44+MHwt+DPh/TPHcng n7/ooA+IPCf/AAUo/YM8WeKvDPw5l/aq+D/w8+Mni7xBo3hPRP2ePjv4lT9nD9qBvFXifUbb TPCHhnVP2Xvj/D8NP2g/D3iDxzJqGj3/AIA0bxD8NdL1Hx74f8ReFvFHg621vw34q8Oarqn2 /XP+LPCfhXx74V8TeBfHXhnw/wCNPBPjTw/rPhPxj4O8WaNp3iPwr4s8K+I9OudH8Q+GfE3h 7WLa80jXvD+u6ReXml6zo2qWd1p2qaddXNjfW09tPLE3xB/w64/YT0f/AJJP8DP+GV/tP/If /wCGGPib8Yv2BP8AhO/J/wCQV/wtH/hin4g/AT/hbH/CMebqX/CE/wDCy/8AhK/+EE/4SHxd /wAIb/YX/CZeK/7YAPv+ivgD/hkv9pjwJ/p3wR/4KMftAf8AEi/0PwB8Lf2o/hp+z3+0n8Cd H8Of8gyy8OeOdQ8OfDX4CfttfFj/AIRjw1K8Xhnxr4t/bp/4WnrHjHS/D3jP4y+P/jF/xWuh eOz/AITP/gpr8O/9E8RfAj9kD9pvw/4c/wCJhrvxE+E/x5+J/wCzP8U/iJo6/wDE21PTPhp+ yf8AFL4QfHH4ZeHfiBYWUs/g7wboXxF/4KHad4E+IniPS9N8VeLvil8CvD/i7UNH+HYB9/0V 8Af8N9f8Il/yX39iv9v/APZ//tD/AJFP/jHH/hsD/hLfsn/Id/5Ro+Mv24/+Fd/2D9p0b/kt X/Cr/wDhLf7a/wCLcf8ACa/8Iz48/wCES9g+Cn7a37I/7RfirUPh58Ff2jfg/wCPfitoPh+6 8TeMfglpvjjRLP4+/DbTtL1HStD8Q23xb+AmsXWm/GT4Q+IPB3iTXNK8JePfCfxO8D+E/FXg DxpeR+DPGmjaF4pWXSIwD6fooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAr4A/4Kc/8S79kTVvH97+58JfAj9oD9ij9qP4rat/rP+EV+BP7Jv7bH7PX 7S/7QHjn7BF5mp65/wAID8EvhR4/8a/8Iz4cstY8Y+Kv7B/4RzwV4e8R+LdU0XQdR+/6+YP2 3fgp4q/aU/Yv/a7/AGc/AuoeH9J8bfH79mD4+/BTwdqniy61Gx8K6b4q+Knwp8WeBfD2oeJr 7R9K17V7Pw/Z6vrtncazdaXoes6jb6dHczWOlajcpFZzAH0/XwB+zP8A8UT+2n/wUo+Fuq/6 R4g+IHxA/Zi/bW0a80/97o9t8LPjB+zF4I/Y68M6Bqdxc/ZL2H4gWPxN/wCCdvxr13XdKtdP vfDlt4E8UfC3U9P8V6n4g1vxZ4Y8E/T/AOz18a/Cv7SnwC+B/wC0Z4F0/wAQaT4J+P3wf+Gn xr8HaX4stdOsfFWm+Ffip4L0Xx14e0/xNY6PquvaRZ+ILPSNds7fWbXS9c1nTrfUY7mGx1XU bZIryb5g/wCSf/8ABU3/AKC3/DW37AH/AF4f8K//AOHd/wC0V/2+/wDCV/8AC3/+HoP/AFLf /Cv/APhR3/M7f8LL/wCLfgH3/RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB4/8NNZ+Muq eNP2hbH4n+E/D/hzwT4c+MGi6N+znrGjXME+o+Pfg1P8Avgf4h1zxZ4sih8Ta7JZ+ILP9oPX vjt4Ftra60vwXO3hXwX4ZvF8M3VtdW/jHxZ7BXgHwb0T+yviL+1jf/8AC9P+Ft/8JN+0B4c1 v/hAP7X/ALS/4Zf+z/ssfs0+HP8AhRf2P/hKfEH/AAj/APwkH/CP/wDDS/8AZH9k+B/O/wCG iP7e/wCEWu/7b/4TXxh7/QAUUUUAFFFFABRRRQAV8Af8E0/+TdfiN/2f/wD8FYv/AF6b+2RX 3/XxB4s/Yw1t/FXibXfgP+2B+0/+yN4b8aeINZ8c+LPhZ8CNG/ZH8R/DPVPiZ4r1G51bx38S dL0X9pj9lT9ofV/AniD4i6vOfEvj/Q/htr/gz4e+LPiFdeKfi/q3gmf4yfE74tfEHx6Afb9F fjD+278If2tP2a/2L/2u/wBozwL/AMFUv239W8bfAH9mD4+/Gvwdpfiz4Xf8Ew77wrqXir4V /CnxZ468Paf4msdH/wCCdGg6veeH7zV9Cs7fWbXS9c0bUbjTpLmGx1XTrl4ryE/Yi+EP7Wn7 Sn7F/wCyJ+0Z46/4Kpftv6T42+P37MHwC+NfjHS/Cfwu/wCCYdj4V03xV8VPhT4T8deIdP8A DNjrH/BOjXtXs/D9nq+u3lvo1rqmuazqNvp0dtDfarqNykt5MAfT/wDwUs/5N1+HP/Z//wDw Sd/9em/sb19/18QeE/2MNbTxV4Z1348ftgftP/tc+G/BfiDRvHPhP4WfHfRv2R/Dnwz0v4me FNRttW8CfEnVNF/Zn/ZU/Z41fx34g+HWrwDxL4A0P4k6/wCM/h74T+IVr4W+L+k+CYPjJ8Mf hL8QfAX2/QAV8Af8FLP+Tdfhz/2f/wD8Enf/AF6b+xvX3/Xn/wAUvhb4E+NHgTXfht8SdC/4 SDwl4g/sye5toNT1jw/rGlax4f1jT/E3hPxd4R8WeGdQ0fxb4E+IHgTxbo+h+Nvh18RfBOue H/Hfw58d+H/DvjnwN4i8P+LfD+jazYgHoFFfAH/DG/7RX/SWL9v/AP8ADc/8Esv/AKWnX5gf tU3v7bvwO/4KT/8ABKX9jrwn/wAFQ/2v9R+GX7dH/Dc//C29d8RfCT/gmpd+O/Dv/DMnwF8O /FLwF/wrrU9N/wCCf2keH9I/tfxBq9zZ+Lv+Em8MeLvt+jpBb6N/YF6smoSgH9H1fAHw5/5S m/tkf9mAf8E0/wD1or/grFR/wxv+0V/0li/b/wD/AA3P/BLL/wClp19AfAv9nvR/gr/wlPiD U/HnxA+N3xg+IH9iQfEj4/fGJvAkvxT8c6P4Q/teH4f+Ebq3+GHgT4YfDLwb8P8A4d2Wva6v g/4dfC34ceAfAln4j8UfEL4nah4d1P4wfFv4vfELx6Ae/wBFFFAHwB8Of+Upv7ZH/ZgH/BNP /wBaK/4KxV9/18wfGv8AZig+KXirT/iV8PvjR8YP2XvjJB4ftfA2ufF/4BwfBq68VeOvhnp+ o6rr+kfDb4heGvj38H/jp8KfGXh/wv4p1rVvFHw+1zWvhzcfEL4V6j4j+Idh8LPG3gvw38Zv jboXxI8f/wCGN/2iv+ksX7f/AP4bn/gll/8AS06APv8Aor+cH/gmNe/tu/to/wDDwn/haX/B UP8Aa/0D/hk3/gp/+1j+xT8Ov+EA+En/AATU0v8Atr4WfAj/AIQH/hEdf8a/8JF/wT+8Vf2j 8QNR/wCEq1D/AISPVdC/4Rzw5eeTZ/2Z4U0fy5/tH6f/APDFXxo1H/iX+MP+Cn37f/jHwlf/ AOh+KfCP9nfsC/DX/hKvDl1+41vw5/wsX4F/sJfCj42+Af7c0x7rTP8AhNfg78Uvhr8U/Cv2 r+3fh94/8HeLbDSPEWnAB/wSd/5RZf8ABNP/ALMA/Y3/APWdfhzXsH7ImjfBrQfhT4ssfgT4 s8QeNPBM/wC0/wDtu6zrmseJrae11Gz+MviP9tD4++If2jPCdtFceGfCcjeH/AX7QeqfE/wL 4TuV0u6gvPCvhzRry18TeNLaeHxjrvv/AIT8J+FfAXhXwz4F8C+GfD/gvwT4L8P6N4T8HeDv Cejad4c8K+E/CvhzTrbR/D3hnwz4e0e2s9I0Hw/oWkWdnpejaNpdna6dpenWttY2NtBbQRRL 5B+zTrf/AAkHw68R3/8Awov/AIZ3+z/tAftY6J/wgH9kf2J/wkH/AAjP7U/xk8Of8L0+x/8A CLeD/O/4ag/sr/hpf+1/7Ju/+Eg/4W3/AG9/wlPjj+0v+E18QABqf7J37LGt+BPil8LdZ/Zp /Z/1f4ZfHH4gah8WPjX8OtT+Dfw6v/Anxg+Ker6xoXiLVfiX8UvCN14cl8P/ABA+IGp+IPC/ hnXdQ8ZeLNP1fxHe6x4d0LU7nUpb3SNPnt+f8e/sRfsX/FTTtS0f4n/sifswfEfSNZ8QR+LN Y0vx78AvhT4w07VvFUXir4t+OovE2pWPiHwnqNtfeII/G3x++O3jGPWbqKXUU8VfGr4t+IVu Rq/xH8Y3ms/T9FAHyBqX/BPz9h3V/in4N+Neofsmfs/3HxN+H/xA+Jfxf8I+Jv8AhV3hKL+y PjZ8YPEfwn8WfEX48/2NBpkXh+//AGgPEXiD4HfC3UP+F76npV78XdI/4Rf7LoXjPTLLW/EV tq/QXX7EX7F99p3xr0e+/ZE/ZgvNI/aU8QaV4s/aL0u6+AXwpuNO+P3irQvFWoeOtD8TfGux m8JvbfFTxBo3jbVtU8Y6VrPjqLXtR07xVqWoeIbO5h1e8uLyT6fooA+QNM/4J7fsC6JrHwt8 RaN+w9+yBpHiD4Hf2f8A8KU13TP2afgvYax8H/7I8d678UtK/wCFW6na+Cor34f/ANmfE3xR 4m+Iun/8InPpH2Lx34i13xdbeV4g1fUNQuPX1/Z6+ASad8R9HT4HfB9dI+Mfh/xB4T+Lulr8 NPBa6d8VPCvizxV8TvHXirwz8R7EaKLbxx4f8S+NvjZ8ZvGPiDRvE8WqadrPir4ufE7xDqNt c6v498VXmrewUUAfMHxO/Yi/Yv8AjZp3h/R/jN+yJ+zB8XNI8J+IPiP4s8K6X8TvgF8KfHun eGvFXxj8VN46+Lvibw/Y+KvCerW2jeIPip42d/GPxH1nTorbUfHHipm8Q+J7nVNXY3h6D4df snfssfB/x3P8UvhJ+zT+z/8AC74m3Pw/8O/Ce5+Ivw6+Dfw68E+O7j4WeENH8I+HfCfw0n8X eGfDmmeIJfh/4X8P/D/wFoXh3wbJqDeHNE0fwT4R0zTdNtrLw3o0Fl7/AEUAFFFFABRRRQAU UUUAFeP/ABr/AGevgF+0p4V0/wAC/tGfA74P/H7wTpPiC18WaX4O+Nfw08F/FTwrpviqx07V dHsfE2n+HvHWi69pFn4gs9I13XNLtdZt7OPUbfTtZ1WxhuUttRvIpvYKKAPgD/h2l+zP4c/e fBG9/aA/ZX/sr/TPAHhj9lz9qL9oT4L/AAJ+FniOH/TLLxH4G/Y68OfEb/hiX/kZd/jfxN4K 8W/s3+K/hZ8U/GN94h1j4y+APiN/wmXjW38Rn/DPH7dngT/kk/8AwUV/4WN/av8AyH/+G5/2 Rvg78aP7H+w/8gr/AIVd/wAMU63/AME1/wDhGv7Q+2al/wAJt/wsv/hdH9sfYfCP/CG/8K5/ srxX/wAJ39/0UAfAH/C5v+Cgnww+X4pfsX/D/wDaG8P2X/FO2fij9in9ovwxb/FPxlrFtxb/ ABF1/wDZ4/bF0v8AZo+GXwZ+H/iGy0/UNR1XwjoX7b37SHjv4d+I9b8K+B9Mn+MHh9fE/wAX NBP+HjXwi8Lf6D8evhB+1/8AsyeINM/f+PIviz+yb8bPFHws+FOjt/pq+LviX+15+z34V+OP 7DHh34f2HheW08aeMviLD+1BqPgT4U+HJdST4weIvh/4g8I+O9B8Lff9FAHgHwL/AGsf2WP2 oP8AhKf+GaP2lv2f/wBoj/hB/wCxP+E1/wCFF/GT4dfFv/hD/wDhJv7X/wCEb/4Sn/hAPEfi D/hH/wDhIP8AhH9e/sT+1vsn9q/2Jq/2D7R/Zt55Pv8AXgHx0/ZO/ZY/ag/4Rb/hpf8AZp/Z /wD2iP8AhB/7b/4Qr/henwb+HXxb/wCEP/4Sb+yP+Ek/4Rb/AIT/AMOeIP8AhH/+Eg/4R/Qf 7b/sn7J/av8AYmkfb/tH9m2fk/P/APw7y8CeDP3/AOzV+0F+1/8AskXq/wDEss7H4T/H3WPi l8LPDXgQfPb/AAt+Gn7L/wC2LpX7Uf7IvwU+H+jTWugw+DdP+CPwB+HOsfDfw54b034e/DbX fCHwy1DxP4L8QAH3/RXwB/wqr/go58Pf3HgD9r39n/47+EvDn/Ey0nQf2o/2V9U0D47fEzy/ +Jtf+DfHP7S/7NHxm+FHwS8A/wBuanJeeFfDPxL8Ff8ABPTXv+FZ+DpPD2p+I/hP8d/FvhzX r/4hH/DQ/wC3Z4E/5Kx/wTq/4WN/av8AyAP+GGP2ufg78aP7H+w/8hX/AIWj/wANraJ/wTX/ AOEa/tD7Zpv/AAhP/CtP+F0f2x9h8Xf8Jl/wrn+yvCn/AAnYB9/0V8Af8PQP2LNI/wBJ+KXx F+IH7Mnh9/3Fn49/bW/Zt/ad/YX+Fmr6w37y38I6B8W/2xfg58Dvhl4i+IF/ZRahrOlfDrQv Fmo+O9X8OaB4r8TaZ4du/D/hHxPqWkfX/wALfix8LPjj4E0L4pfBT4l/D/4wfDLxR/af/CM/ EX4W+MvDnxA8CeIv7E1jUPDus/2F4u8J6lq/h/V/7I8QaRquhan/AGfqFx9g1jTNQ0y68q9s rmCIA9AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAPgD/glx/wASb9hP4GfCb/j5 /wCGV/8AhZv7DH9v/wCp/wCE7/4YE+MXxB/Yp/4Wj/ZX73/hGP8AhbH/AAoT/hZf/CE/2l4h /wCEE/4Sv/hDf+Eu8Zf2F/wlesH7TH/FE/tp/wDBNf4paV/pHiD4gfED9p39inWbPUP3uj23 ws+MH7MXjf8AbF8Ta/plvbfZL2H4gWPxN/4J2/BTQtC1W61C98OW3gTxR8UtM1DwpqfiDW/C fifwT8Qa9+294V/4J4/Ez9rz9lDTvA/iD4yftI/FT9p+L4w/8E4v2Evh7qOnP8TPjz4V/bD+ Htl8UviB4yt/G2orqlh4C+D7/t4eE/8AgoN8R/j98WPi3rMmnfswfD3SZtSvtE0b4Xa5+zH4 F8a+P/8ABQv9nb/gtX8U/gTpn7Rtr+0j+z/8O/HX7J3xA8VftReFv2Nf2J/gDr3jH4p/EXR/ h34xn1XRPhr8Of25Pjp4e+MHjO4/aA1v9nKy8YfDHR9U+Hv7Bfw78CfGjxH8YfiJ8APjF8I/ HfwF+Imr6bQB/R9RX4g/C3/glPdaj470L9rD4Y/8Fs/+Cv8A4+/4T7+0/il4T1WD9rD9nH4r /s4+KtH+K+j6hqFtrvhH4Kaz+yz4q/Zl1H4f6joviptW+HWmeH/h3J4E8K2r+HdY+HGn6H/Y fhm6070D9m/w/wD8FP8A4HeBNY8R+K/2yf2f/wDgsH4ftPiB430rxBZaZ8FvAH7Fnxs8O/8A CB6xJ4K+I/gz4W+P/hj8Q/iJ+zl8RPiB8O/Gfw78Z+ANP+A/xe8FfAT7f8XfE+u2XxU/bH+E Xh/4dt4clAP1+orx/wCCnx++DX7RfhXUPGPwV+IXh/x7pGg+ILrwZ4xs9Nmns/FXw2+IWl6d pWqeIfhX8W/AusW+m+NvhD8YPB1trmlRePfhD8TvD3hP4meANRvI9H8aeFNC1dZbGP2CgAor wD9qP46f8M4fAnxz8WLLwt/wn3i3Tv8AhGfB/wAKfhp/bf8Awiv/AAtn47fFfxj4e+E37P8A 8Hf+Eyl0jXdM8B/8Le+NvjfwB8NP+FheI9Nfwd4A/wCEq/4TLxrdad4S0PWtStPn/wD4dw/s 4/E//irP20/AHw//AG6PjBq3/Ew13xR+0f4FtfiX8LPBusXfGp6Z+zH+zv8AFLVviZ8Mv2Vf h+9lBoXhmTQvhdbJ47+InhzwN8P9Z/aT+KX7Qfxg0DUPi5rwB9/18wftM/tU+Ff2adO8HWZ+ HXxg+PHxW+JfiDTtA+GX7Pn7PHhHTvHPxl8bwS+KvB/hTxR43Gna94i8HeCfAPwf+F9z488K 33xc+OXxd8dfDr4NfDaDxD4X0vxV470/xT458BeHfFPj/wDw6x/4J96R/pPwt/Ze+H/7MniB /wBxeePf2KZ/E/7C/wAU9X0dv3lx4R1/4t/sda/8Dvib4i+H9/exafrOq/DrXfFmo+BNX8R6 B4V8Tan4du/EHhHwxqWkeP8Ahn4EfDP9n7/gp5+zLZ/D7S/EGo6v48/4Jwftn+E/FnxB+Lfj /wCIX7Qfxl1jwr8Cf2tP2MvGvww8MyfHL4++KfiZ8ZLXw/oXiT9rn45X2paNY+OrXTvGEGr+ AtL8a23iLSPgh8DrH4cgHsH/AAjn/BU3xb/xUP8AwuT9gD9n/wDtD/mkX/DNP7RX7YH/AAiX 2T/Qf+Ti/wDhrH9hz/hYn9vfZv8AhJv+TXPhf/wiX9tf8IN/xWv/AAjP/CxPFp/w0P8At2eH /wDilPGH/BOr/hJviBrf/IreMvgF+1z8HfHH7LHh/wDtL/iW6J/wur4l/HTRP2X/ANprwf8A 2VrUN1qvxH/4U7+xT+0R/wAI/wDDq40bX/h9/wALb+IF3q/wn8P/AJA/sg/t4ap4++BP7Bnx Q8Jf8FgP+Gxv2x/jZ/wwh/wuP9gb+2/+CcfiLZ/wvzxj8GPD37Yn/Fn/ANm/9mz4cftW+Gv+ GW/hZ45+Mvxn+T4mW/8Awqj/AIU7/wAJR8bv+Es+G/hH4h+H9c+3/wBp/wD4Kp/D3Tf2bvAf jH4Z+I/EHwb1f4p+H/2dPE3xU+I3j6w+GdlP+wX8PfjH+3T+zf8AsWfFa2/aWj8SeI/FPgn4 E/tP/Da5+K/7QUXgHwn8XPD3jf4Z6Z8Zf2M/2ltH+JWjeLdI+APxD8B60AfT/wDwzz+2n8T/ APirPil+3t8QP2efEF7zZ/CT9in4W/sxXHws8G6Pc/8AEyt9A1/x7+2L+zh+0v8AE34zfEDw 9e6hqHhnVfjRoVt+zf4E+InhzRPCus6Z+yr8H/EDeJ49eP8Ahmn9rv4e/wDFa+AP+ChP7QHx 38W+HP8AiZaT8Gv2o/BX7FGgfAn4meX8l/4N8c+Lf2aP2HvhR8bfAP8AbmmSXln4Z+JfgrxH r3/Cs/GMnh7x/wCI/hP8d/CXhzXvgj8Qj9hj4k/8Jn/wtHQf+Gqf2gP2iP8AhHf+EJ1f/hHP 2xP2U/8Ahkr9qf4e/wDCTf8ACXWX9t6n4K/4Z4/Y8/4ST9n/AMff8It9g+D/AIp/4ZotN/xF 8AftB6T/AML0+Kf9m/8ACAfAz7/oA8A/Zv8A2l/hZ+1N4E1jxr8MdW3Xvgn4geN/g18XvAGp 3/hy58d/A/47fC3WJPDnxU+CPxSs/CmveKPD+mfED4f+IImstQfw/wCI/Eng7xRo9zoXj/4c eLfG3wy8X+DPGviH3+viD4AXPhVv2wv2/LP4b6N4gg8NweIP2a7n40eIbnxNp114V1T9sK6+ BmnReOdG0bwdqnhOz8eaF4g0L9jyz/YLvvE3ibT/AB14j+BnizTvEfhPS/h/4T8F/GTwX+0r rHj37foA+YPgFrPwa1T4rftu2Pww8J+IPDnjbw5+0/4T0b9ozWNZuZ59O8e/GWf9i/8AZE8Q 6H4s8JxTeJtdjs/D9n+z5r3wJ8C3Nta6X4LgbxV4L8TXjeGbq5urjxj4s+n68f8AhprPxl1T xp+0LY/E/wAJ+H/Dngnw58YNF0b9nPWNGuYJ9R8e/Bqf4BfA/wAQ654s8WRQ+Jtdks/EFn+0 Hr3x28C21tdaX4Lnbwr4L8M3i+Gbq2urfxj4s9goAKK/OD9pn/gon4V+GXxl8HfsffsyeE/D /wC19+3h428QadDefs1+F/ifp3hDTvgL8M7aDwf4g8dfH79sP4kaX4a+JNz+zT8H/C3gjxv4 Z1Xwxca94A8SfEL4z+KvF/gTwN8Gvh742v8AxJfaj4f6D/hnn9tP4n/8VZ8Uv29viB+zz4gv ebP4SfsU/C39mK4+Fng3R7n/AImVvoGv+Pf2xf2cP2l/ib8ZviB4evdQ1Dwzqvxo0K2/Zv8A AnxE8OaJ4V1nTP2Vfg/4gbxPHrwB9/0V+MPwU/4I9+NPgD4q1Dxj4F/4LHf8Fntd1fUvD914 ZuLP41/tL/AL9pTwrHp15qOlapNc6f4F/aM/ZQ+KngnSfECXOjWcVr4s0vw9Z+KrHTptV0ex 1m30jXdcsdR6Dxr8Uv8AgoJ+zJ4cvfiz8Kdd+H//AAVn/ZY+Hf8Awn+j/Ezwz4c0zwx8O/8A go5p2sfD/wCKfhzwn8UJPAGs/BjT7L9kX9q34gfCWbSv2gPDl7+zfovwR/Yt8drqnw78FfCq Lxv8RPjPF4oufFwB+v1FeAfs0ftVfs4/tkfCzSfjX+y58aPh/wDHH4Zav9gg/wCEm8Aa/a6v /YWsX/hzQfFn/CI+NdGzF4g+H/xA0zw/4o8Pah4j+HXjnSvDvjvwp/a9na+JvDukXsv2Ye/0 AFFFFAHwB/wVi/5RZf8ABSz/ALMA/bI/9Z1+I1H/AASd/wCUWX/BNP8A7MA/Y3/9Z1+HNH/B WL/lFl/wUs/7MA/bI/8AWdfiNR/wSd/5RZf8E0/+zAP2N/8A1nX4c0Aff9FFFABRRRQAV+AP /BQ//lOv/wAG6v8A3ly/9Y88E1+/1fgD/wAFD/8AlOv/AMG6v/eXL/1jzwTQB+/1FFFABRRR QAUUUUAfgD/wQL/5zUf9p/v+Cjf/ALxuv3+r8Af+CBf/ADmo/wC0/wB/wUb/APeN1+/1ABXj /wAD9G+Mug+C9asfjt4s8P8AjTxtP8YP2hdZ0PWPDNtBa6dZ/BrxH8ffiX4h/Zz8J3MVv4Z8 Jxt4g8Bfs+ap8MPAviy5bS7qe88VeHNZvLrxN40uZ5vGOu+wV8wfsiaN8GtB+FPiyx+BPizx B408Ez/tP/tu6zrmseJrae11Gz+MviP9tD4++If2jPCdtFceGfCcjeH/AAF+0HqnxP8AAvhO 5XS7qC88K+HNGvLXxN40tp4fGOugH0/RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABXyB8Uv+Cfn7Dvxo8d678W/iT+yZ+z/wCIPjb4g/sye5/aCg+F 3hLw/wDtHaVrHh/R9P0Hwn4u8I/tE+GdM0f42+BPiB4E0zR9Dj+HXxF8E+PfD/jv4c3Xh/w7 qXgbxF4f1Pw/o15Y/X9FAHwB/wAMC/8ACJf8kC/bU/b/AP2f/wC0P+Rs/wCMjv8AhsD/AIS3 7J/yAv8AlJd4N/bj/wCFd/2D9p1n/kiv/Cr/APhLf7a/4uP/AMJr/wAIz4D/AOESP7N/4Km+ BP8Aib/8Jl+wB+1R9p/4lv8Awr3/AIVp+0V+wJ/Y/nf6V/wmX/C4v+Fsf8FKP+El/s/7H/Yn /CtP+FF+FP7Y/wCEh/4Sn/hbGhf8Ib/wh/jv7/ooA+AP+GtP2mPAn+g/G7/gnP8AtAf8SL/T PH/xS/Zc+Jf7Pf7SfwJ0fw5/yE73xH4G0/xH8SvgJ+218WP+EY8NSpL4m8FeEv2Fv+Fp6x4x 0vxD4M+DXgD4xf8AFFa747P+Ho/7Cej/APJWPjn/AMMr/af+QB/w3P8ADL4xfsCf8J35P/IV /wCFXf8ADa3w++An/C2P+EY83Tf+E2/4Vp/wlf8Awgn/AAkPhH/hMv7C/wCEy8Kf2x9/0UAF FfAH/DrH/gn3pH+k/C39l74f/syeIH/cXnj39imfxP8AsL/FPV9Hb95ceEdf+Lf7HWv/AAO+ JviL4f397Fp+s6r8Otd8Waj4E1fxHoHhXxNqfh278QeEfDGpaQf8MXfF3wT8vwF/4KEftf8A w/8AD+g/8TDwH8JPizP8E/2sPhZbaxF/xMm0z4l+Pf2hPhF4v/bn+KPw/wDEnihrvUfGWhTf tveF/Hdt4c1fUvA/wf8Ail8GfD+meBI/BIB9/wBFfAH9pf8ABU3wJ/xKP+EN/YA/ao+0/wDE y/4WF/wsv9or9gT+x/O/0X/hDf8AhTv/AAqf/gpR/wAJL/Z/2P8Atv8A4WX/AML08Kf2x/wk P/CLf8Kn0L/hDf8AhMPHZ/w3d4j8K/8AEw+On7BH7f8A8CPCU3+h6d4u/wCFTfCz9rL+0fEc n7+08Of8K6/4J0fHD9tH426L9s0y31fU/wDhNfFPwt0D4Wad/Y/9ha34/wBL8W+I/A/h3xUA ff8ARXxB4T/4KUfsGeLPFXhn4cy/tVfB/wCHnxk8XeING8J6J+zx8d/Eqfs4ftQN4q8T6jba Z4Q8M6p+y98f4fhp+0H4e8QeOZNQ0e/8AaN4h+Gul6j498P+IvC3ijwdba34b8VeHNV1T7fo AKKKKACiiigArwD9pD46f8KH8CaPqujeFv8AhYnxN+InxA8EfB34KfC2HW/7BuviH8U/iJrE emaVa3eoWukeKPEGmfD/AOH/AIfi8TfGn49eMPCfgf4ieI/hT+zj8MPjB8Y7b4e+MrL4d6ho V57/AF+cGjW3ir4+/wDBS7xZ4ofWfD+pfs+fsC/B+2+Fek+GLjwzqNxqMn7ef7Smk+GfiV8Q fFc1/rXiyPTtO8QfAL9i+++DOg/D3xn4Y+GUz33hX9vf4/eAtO+L0slv8U/hzpwB8gaJ+xD4 V/4Jo+KvhP8At/65448QftCfHafxB4y8Cf8ABTz9rj4m6dp1r4++LXwk/aj1H4PaX4o+OQ0z TW0/wt8Gfg/+x/8AFb4K/s5+IPD/AIIm8Z6H+zx+yB/wT08OftWatb6B40+JMdj4u1X93q5/ xZ4T8K+PfCvibwL468M+H/Gngnxp4f1nwn4x8HeLNG07xH4V8WeFfEenXOj+IfDPibw9rFte aRr3h/XdIvLzS9Z0bVLO607VNOurmxvrae2nlib8gZPirp3/AARg8K+PY/2qPiz4gvP+CWvh Pw/8JPDn7JnxBsfgj4q8e+Kv2KNO0LTtN+FkH7Jvxv1b4JeHPEfjfxp8H57a18A3H7LXx/8A GXw713xVLqLfEb4UftR/G7VPiXefs+a18cwD5f8A2qvF37R3/BIjwJ8aPhP+zx4d/Z/+E/7C f7Qv9v6F+xf8fr6C6+GPwi/4JOftY/HvWDDrGn/tT29l8Ovjnpj/ALIHxC+NvjPxR8c/gf8A FI/DSX4bfCT42eKE/ZF+LmmfCr9m3xP8IPiF8OPzB/4NNf2Xv2+v2U/Hf7efgDWfFn7P/jj9 kX4f/tf/ABc/ZN+Nfhxfin8aIvHfgX9qf9l/R9Ns9V+L37Pfgq6+GLfDLxJ8P/ijZeL/AAz4 K8d3Hiy8+GXxF8UaP4X8B+I7m70yH4S6f4A8f/u9pv7XH7ef7XHir4t/DnwJ/wAEgfD8/wCx f4k8P+PfCfh74w/8FDv2k3/Zig/aE8K2uox/Dbxj4Z8VfsYS/so/tD/tB+BPD/xFkn8YX/g7 Rvjh8NfDmneO/g1YWnijxbbeEdR8aaP4Dn/CH/gjJ8O/+CuHgT4p/wDBQDU/2FtH/YA8Cfsy +BP+Cv8A+3D8O/j1+x18WviN430f4WaP4j0fxH+z/cXej/sreJ/g/wDsT6P8QPAn/CCfD/R7 74W+BfiN4z13WPhZrHhzWND1CX9ifwJrXgSa88dgH9Pv7Yv7Pfxd1LWLP9rP9k/x58QPCX7T Xwd+H9xYyfB7wY3wT0vwJ+3T4E8JeO/DHxY039lj47638W/AniD/AIR//hIP+Ef+Inww+A3x w0nxX4S1j9lbWP2k/i/8RNHfXdF8W+PfBvi7oPFf7XmnfEDTvhD4J/ZOvfD/AI1+Mn7SHh/4 qeIPh1feP9B8VaL4L+D/AIL+BfirwZ8Pv2hvib8d/BWpy+BPiJB4g/Z4+InxF8FfC7xT+yn5 /gb4++IPj74h0v4L+Mj8CPDehfHX45/AD+GL9mf/AILCf8F2/hn/AMFTf23vhX8Ovhz8QP2y PgL4P/b/APi94Y+PXwYuvBX7Sn7Xfws/ZV0fxX+0VqHhy7t/h98e/g/8D9e/aN+Hfw/8G+DP hh4u8KfB2zg+EOu+BE8OWPjDxn4d/Y68ReOjN4Yg/oe/4JjftMfsj/EX/gsX/wAFSvin8Kf2 wv2YPitpH/BQv4P/APBMf4yfs1+F/BPxb0ST4ma/p3ww/Z+/aC8BfEjwDrnwy8QLoHjbR/jB 8Orb4Z3HxB+JPwvj0W/8VfDP4e+MfA2rfESy8Lavq2o6Do4B+n7f8E9dR+JfxC+HHxP/AGs/ 2v8A9p/9pK5+G3iDw/8AEnw98DNP8R+Ff2dP2R/D3xl8M/Ez4Y/GTwp420r4Pfs+eGPAvxE+ JHh/4W/ET4V+H7r4KeBv2u/jt+1bB4G0SS6XxDrnj/xtd6j4+1D9H6K8/wDil8WPhZ8DvAmu /FL41/Ev4f8Awf8Ahl4X/sz/AISb4i/FLxl4c+H/AIE8O/23rGn+HdG/t3xd4s1LSPD+kf2v 4g1fStC0z+0NQt/t+sanp+mWvm3t7bQSgHoFeAeI/gX/AMJB+1P8G/2l/wDhKfsn/CpP2f8A 9pb4F/8ACFf2J9o/4SD/AIaI+Iv7J3j/AP4Sn/hI/wC14f7K/wCEP/4Zf/sn+xP7B1L/AISD /hOPt/8Aa+if8Iz9j8QfP/8Aw9i/4JZf9JLP2AP/ABMj9nX/AOeNR/w9i/4JZf8ASSz9gD/x Mj9nX/541AH0B+yd8C/+GX/2WP2af2aP+Ep/4Tj/AIZ3/Z/+DfwL/wCE1/sT/hGf+Ew/4VJ8 OvDngD/hKf8AhHP7X8Qf8I//AMJB/wAI/wD2t/Yn9va3/ZX2v7B/a+pfZ/tk3x/ff8ExvAlv a/tT3ng/xp/wi/i345/tAfA/9oT4X61P4c1jX9H+Emsfs9ftHJ+3l4B8B+LvD174+t7j4t/D /W/+Cg/jj9pn9on4irp2vfCvx3rfgT9pXxF+z74O8d/D3wl8Mfg3r/gf0D/h6p/wTj1H/QvA H7Z/7P8A8d/Fs3/IJ+FP7Lnj7S/2svjt4q8v97f/APCDfs//ALND/Ff42+Pv7D0xLzxH4m/4 QrwBr/8Awivg7R/EPjXxH/ZfhLw5r2tacf8ADyz9nX/onP7f/wD4qd/4Km//AEG9AHoH7PX7 PXxT8CfFP4t/tAftAfFv4f8AxY+NvxY+H/wZ+Dt5e/B34M+I/gJ8LNH+FnwE8R/HDxr4AtbX wB41+N/7R3i26+IF14t/aO+K0vjDxhL8VovDmseHIvh9oui/D3wxqfhjxH4j8d/X9fAH/Dyz 9nX/AKJz+3//AOKnf+Cpv/0G9H/DxP4deIP+JR8J/wBnL9v/AOLfxAu/+QB8Pf8Ahgf9qf8A Z3/4SD7P/pWq/wDF4v21vhp+y/8Asy+D/wCytFh1LW/+Ll/HTwP/AMJB/Zv/AAi3g3/hJviB rfhTwf4gAOfn/Yv/AGh4Pjf+1D418C/tv+IPgX8Kf2lPjB4R+PdxoPwU/Z++Elx8ffDnxC8L /s1fs/fsyTeHNQ+Mv7Rg/aQ+DfiH4P614b+BFn4yuvDGl/sneDfiZa+NNS0r7D8Z4fC2i654 Z8aH7J/xJ/a4+HHxl1b9jf8Abl8bfB/4x+Nv+FP6P8W/2af2nfhP4G1v4S6j+0v8PfhxB8O/ h1+0tJ8YfgX/AG58QPC3wf8AjB8H/it8QPhbret6l4U8f2fwz+LvhX9ofwbc/CTwF4Sufhr8 WPCvhHoP+GyP2iv+kTv7f/8A4cb/AIJZf/TLK8A+KH7Tf7bv/C0/gx8Uvhb/AMEoP2//ABH/ AMI5/wAJR8L/AIi/Drxb+1r/AME1PhZ8LP8AhVnxT8R/DPxF4u+M6eEfDv7Y/wAWv+FtftAf CX/hUun6F8EfC+u6h8LPDn/COfFP4y6ZqfxM8Of8JHBPQB9//BvRP7K+Iv7WN/8A8L0/4W3/ AMJN+0B4c1v/AIQD+1/7S/4Zf+z/ALLH7NPhz/hRf2P/AISnxB/wj/8AwkH/AAj/APw0v/ZH 9k+B/O/4aI/t7/hFrv8Atv8A4TXxh8v/APBQD47/AB98P6j8Av2Qf2O9U8P+FP2sf2y/EHj/ AEfw58X/ABl4A8afETwX+yx8AvhN4Vttf+P/AO1hrfhrRPC2qeCPFXiD4eXPif4W/C/4PfDv 4o+L/h94L8dfH344/Cez8Ratq/g7T/F+hXvzB8G/26fEfjX9pj9rH9n/APZX/wCCefxA+GX7 VqfEDw58Yv2nLL9uf9on4WfAz4WeLvEdl+z3+zT4Kkuvhd4//Zw8T/8ABQjU/iJ8QPB/wS1T 9kKLxt4P+FXwpsvhZ8N/DnjPwjrXxm+IXw9+KfxN+H/hz4y8/wDBLx9/wUk+JH7YX7ZXxXvP 2UP2IPEHjb4C+IPht+xl4e0bWv8AgoN8edK8K/CvwrN8DPgr+114xm+Gl5L/AMEyfGWr6n4g +Nur/tG+BZPjh46sbf4T6d46074G/s9fDvVPhRfXP7Oej/GH4pAH7PfDr4daP8OdHntraf8A 4SDxb4g/4R3U/id8TtT8O+BPD/jv40eO/D/gTwj8OG+KXxSb4ceEfAnhLWPiBrHhLwJ4T0bU NQ0bwn4f0ex0fw/oXhnwzoXh/wAJeH/D/h/SvQK+AP8AhY3/AAVN/wCjN/2AP/Fln7RX/wBK drz/AOLPxj/4KJeCfhZ8S/ip8UtK/YA/Yv8Ahl8Fvh/4y+MfxF+M/wDwnH7UX/BRb7N4E+HP hzUvEfi7Sv8AhQnh34Lf8E7fEFj5Ph+01DxX/wAJxoXxe8faxbf8It/whmmfBbxVe+N4PE/g kA9g/wCCivgn9tD4ofsj/Fj4UfsE658H/BP7QfxW8P6r8ONO+Kfxk+JPxW+GGnfB7wr4v0TV 9J8T/E7wDrXwZ8DeNPG118YPDltPBH8L1guPCGneGfFV/ZfETUPEGrR+CU+H3jf8If8Ag1n/ AGGf24v2DvhF+014C+NfjL9n/wAa/sy+Mf2gPjdp/giy+HXjHxbdeO/Av7R37M3xs8c/shfH LU59B1/4B+E/+Ei+H/xi/wCFJ6VqXh3XdQ+LYuvCej/DXwjJa/C2w1r4n+O5fC/r/wAMfjx/ wc9/HjUfEHiH4d/s7/8ABOD4J/BuTw/8OPE3wv8AEf7eXwr+OvwB+MvxF07xx4VXW9atta+A H7O37av7a2r/AAe8QeA9XSTR/EPhP4reMfDXiqKDUdBluNGsfEh8ZeEPA3kH7D3/ABEj/wDC l/Gv/Cnf+HIP/CJf8Nf/APBQn+1/+Fl/8N5f8JH/AMLT/wCG+v2lv+F6f2b/AMIt/wASz/hX /wDwu3/hYP8Awqf7V/xUf/CrP+EN/wCEw/4q3+26AP2e/a8+APxl8Daje/tg/wDBPb4e/B8f tfaX4g0HXvjh8OfEEMHw807/AIKFfBrw14Vl8L3v7PvxN+JWnXFnpGg/GDQdIs/Dmqfsp/tE /EvQvHE/wP8AFXhU/DD7Z4Y+APxs+Plhr/1/+z18a/Cv7SnwC+B/7RngXT/EGk+Cfj98H/hp 8a/B2l+LLXTrHxVpvhX4qeC9F8deHtP8TWOj6rr2kWfiCz0jXbO31m10vXNZ0631GO5hsdV1 G2SK8m/z4/8Ag3//AGpv+Div9vLx38PPBXhn9p79oDxB+wL8MfiBqHgr9oH9oXxdP+y9f+O/ CP8Awkuj+KvHk9l4d+O/7UP7OH7S/wATfjN8QPD17qGjXkHgC28OfEj+xdH174deAPFniP4C fDrxn4R+JHhT+j79i34L/tRWH7ZP/BSf9hqP9uf9v/4UfDL9mT4gfB79of4OfEL/AIQP/gna 3/C8dH/4KFWPxN+P3xp8U+T44/4Js6vDq/8AZH7XWkftIWv/AAlfgjxBH4Ei/tD/AIVTo/gv wje/CHVbjxEAf0fUV8Af8Mb/ALRX/SWL9v8A/wDDc/8ABLL/AOlp0f8ADAv/AAlv/Jff21P2 /wD9oD+z/wDkU/8AjI7/AIY//wCES+1/8h3/AJRo+Df2HP8AhYn9vfZtG/5LV/wtD/hEv7F/ 4tx/whX/AAk3jz/hLQA/4Kxf8osv+Cln/ZgH7ZH/AKzr8RqP+CTv/KLL/gmn/wBmAfsb/wDr Ovw5r4g/4Kbf8E+fgN4L/wCCbf8AwUG8Y6P4+/bfvNX8J/sQftX+JtLs/Fn/AAU2/wCCknj3 wrdajoXwG8fapY23ibwL46/av8R+CfGnh+e5tYotZ8J+MfD2u+FfEenNc6P4h0bVNIvLyxnP +CZP/BPn4DeNP+Cbf/BPnxjrHj79t+z1fxZ+xB+yh4m1Sz8J/wDBTb/gpJ4C8K2uo678BvAO qX1t4Z8C+Bf2r/DngnwX4fgubqWLRvCfg7w9oXhXw5py22j+HtG0vSLOzsYAD93qK+AP+HXH 7Cesf8lY+Bn/AA1R9m/5AH/Dc/xN+MX7ff8Awgnnf8hX/hV3/Da3xB+Pf/Cp/wDhJ/K03/hN v+Faf8Ip/wAJ3/wj3hH/AITL+3f+EN8Kf2Of8Onf+CWX/SNP9gD/AMQ3/Z1/+dzQB9/0V+YH xF/4I2f8E4/F+jwf8K2/Zl+H/wCyJ8TdC/4SK8+Hv7Rf7C2iaX+xv+0d8LvEfiLwJ4u+Hc3i PwZ8XfgDYeCfEFz9m8P+Ntc83wV42/4TD4WeJLo2P/Cc+APFdlY29ivQfsafEn9ofwb8Zf2i v2M/2uPG3iD4p+Nvh14gHxb/AGV/2jPF3gb4SfDPUf2pf2R/HEGiTXMk+h/CjXLHwt4m+MH7 JfxW1jU/gX+0DqXhH4RfBrRLTwrr/wCy98SdT8BaPc/tAaNcauAfo/X4A/8ABQ//AJTr/wDB ur/3ly/9Y88E1+/1fgD/AMFD/wDlOv8A8G6v/eXL/wBY88E0Afv9RRRQAUUUUAFFFFAH4A/8 EC/+c1H/AGn+/wCCjf8A7xuv3+r8Af8AggX/AM5qP+0/3/BRv/3jdfv9QAV4B+zTrf8AwkHw 68R3/wDwov8A4Z3+z/tAftY6J/wgH9kf2J/wkH/CM/tT/GTw5/wvT7H/AMIt4P8AO/4ag/sr /hpf+1/7Ju/+Eg/4W3/b3/CU+OP7S/4TXxB7/Xj/AMD9G+Mug+C9asfjt4s8P+NPG0/xg/aF 1nQ9Y8M20Frp1n8GvEfx9+JfiH9nPwncxW/hnwnG3iDwF+z5qnww8C+LLltLup7zxV4c1m8u vE3jS5nm8Y66AewUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHP+LPCfhXx74V8TeBfHXhnw/wCNPBPjTw/rPhPx j4O8WaNp3iPwr4s8K+I9OudH8Q+GfE3h7WLa80jXvD+u6ReXml6zo2qWd1p2qaddXNjfW09t PLE3xB/w6/8A2LNI/wBG+Fvw6+IH7Mnh9/3954C/Yp/aS/ad/YX+Fmr6w37u48Xa/wDCT9jr 4x/A74ZeIviBf2UWn6NqvxF13wnqPjvV/DmgeFfDOp+Irvw/4R8MabpH3/RQB8Af8Mz/ALaf gn/ia/C3/gpR8QPiB4guP+JfeaN+2t+zH+zF8YPhZbaPL/pNxqegeGf2OvBH/BO34m2PxAhv bTT7XStd1341+KPAlt4cvfFen6n8Ldb8Qan4Y8WeCT/hM/8Agpr8O/8ARPEXwI/ZA/ab8P8A hz/iYa78RPhP8efif+zP8U/iJo6/8TbU9M+Gn7J/xS+EHxx+GXh34gWFlLP4O8G6F8Rf+Ch2 neBPiJ4j0vTfFXi74pfArw/4u1DR/h39/wBFAHwB/wAPB/DnhX/iX/HT9k79v/4EeLZv9M07 wj/wx58U/wBrL+0fDkn7i08R/wDCxf8AgnRZfto/BLRftmp2+r6Z/wAIV4p+KWgfFPTv7H/t 3W/AGl+EvEfgfxF4q9g+Cn7bv7F/7SnirUPAv7Of7Xf7MHx+8baT4fuvFmqeDvgp8ffhT8VP FWm+FbHUdK0e+8Tah4e8C+LNe1ez8P2er67oel3Ws3FnHp1vqOs6VYzXKXOo2cU30/Xj/wAa /wBnr4BftKeFdP8AAv7RnwO+D/x+8E6T4gtfFml+DvjX8NPBfxU8K6b4qsdO1XR7HxNp/h7x 1ouvaRZ+ILPSNd1zS7XWbezj1G307WdVsYblLbUbyKYA9gr4A/Y3/wCTiv8AgrF/2f8A/Dj/ ANdZf8E06P8Ah1/+xZpH+jfC34dfED9mTw+/7+88BfsU/tJftO/sL/CzV9Yb93ceLtf+En7H Xxj+B3wy8RfEC/sotP0bVfiLrvhPUfHer+HNA8K+GdT8RXfh/wAI+GNN0j8wPjB+zZ4t/YP/ AOCgnwF+Ivwy/bT/AGgPhf4S/wCCiH2v9l/xb8SfiroX7DvxL8CXX7Tv7P8A4Ym8c/8ABNv4 H/tBa54/+F3w9/at+Ofw/wDGfwtT9qz4J614/Hx08Tftp/GvWNJ+AHwu8QftY+G/Ft34M8bR gH7f/G39qr9nH9nDWPhR4Z+OXxo+H/w18W/Hf4geFfhb8FPBPiLX7WPx38WfHfjHx34G+G2l aF8OvA1qbrxb4x+weLfiV4ItvF2p6Bo1/o/gDR9fg8WeO9Q8OeErXUNctPgD/grj8C/+Go7r /gmZ+zfrPin+xvhl8Uv+Cn/wl1v41+ENT0T/AIS/wJ8a/hZ+zr+zj+1X+1zqvwL+KXgK61fS fD/jn4f/ABL8Qfs+eGdH1DSPFkeu+HNG1hdC8b3PhbxJe+E9P0i6/nB/ar/4Nl/+Cmuv/tf/ ALOf7b2oft+f8PLPiB4M/aA+GPi74naH8YPFnxP/AGIPHfhzwJpn7QHhPxs3h34C/En4ceMP jZ/wp34f+Hf+Es+KPji7g+D7fC3WPgRo+kzaj+zf8OviF8QNT8P+Bo/v/wDaW/Z3+JPw/wDj R/wT20P4pfsg/t/+JPEGs/tf+NZLOb9lz/guT+1j+0V4O8UaO37Av7cNxb+CPA3xC/bF/bB/ Ye+Jvwn/AGgNPvdG1Dxz4m1jQvht4Q8CS/AnQvEPgnTP2kPFniD4o+J/gDqYB+r2ofsieKv2 DtO1X4g/sK/Hf4P/ALM/7J3gLw/8a/iv8Xf2Nv2jdC1HVP2R11vW/FVr8XvFXjr4VfGseN9I 8bf8E+vD5ttP8caL4kh8KaT8ZP2R/hdoniy/+Kfhr9jJvGOjeKpPiJ+cP/BJD47ax+yb4E+P Pjr48/sz/tf/APCJf8FLv2v/ANq3/gpz8LfjX+zx+zn47/bC/Zxm8CftAax8KLr4Z+C/C2q/ syW3xK/atsP+Ex+Ft14U+KfhTxH+1P8Asbfsgaxqlre+NPB2qeAfD/i3wBeafrHv/wDxqJ/5 r7/w3/8A8Kl/5mz/AIej/wDD6/8A4YT/AOoF/wALz/4eXf8AGEv/ACMv9jf8Ky/4XV/zWL/h X3/CuP8Ai7X/AAgdff8A/wAPYv8Agll/0ks/YA/8TI/Z1/8AnjUAHwt/4KB/8Eyv7Y0L4SfD b9rP9kDwP8QPHHxA1OC2/Z9n+KPww+Enxs/4XZ8W/Heoa94s8I+Lv2dvE2p+Evi14S/aA8W/ FrxbrknxF+HXjbwFonxd/wCFu634i03xz4dt/iBcazZ1+MP/AAVjX4BfHT/grv8As2fsf3v/ AATP8P8A/BQH47eO/wDgnB8d9N8Q2vjnTfBfw9+Gfg34Z/G/9pv4HeG/B3xb+JP7UsWieOvi t8CvD/7OHhb4P/tb6rofj3wN4A1j4heF/iF8b/BPgb4Ax33xJ+POsPov6/eLP+CkP/BNH4qe FfE3w80f4+fB/wDbP0jxj4f1nwz49+CP7K3h7Vv+ChfirVvh74h0650PxTc/EX4CfspeF/j9 42j+D99bajF4S8XeLPGPgeH4ZpqPinw74M8Q6zHq/jXw5pGs/wA0X7Cnin/gkL8c/wDgoJ/w Uq+JLfsDfD/42/sS+I/h/wDsHT/sEXPwt/4ImfFj4p+BE8CaZ4Y/aE8M/H/xdoXhP4TfsSeI Na8P/wDCQftNeH/id4J1P4i/EfQ9M1j4hax8LNQ8DeH/ABF4j8NfBKw0bwYAfv8Afsq/8EPf +Cdv7P8A+zj8F/gp8Tv2Tf2QP2oPiB8Mvh/oHhHxZ8fvil+xZ+y7ZeO/ihrGlWohufEWu2+j fDP/AHdP0yfxBqvjDx3d6PZafdfEf4i/E34gTeJviF4m9/8A+GTv+CWX7Dn/ABlH/wAM0/sA fsf/APCr/wDm4v8A4U3+zr+z/wD8K7/4TX/i3f8AyV3/AIRzwl/wiX/CW/8ACW/8IN/yMOn/ ANvf8JN/wjP+l/219hufgD/hCf8AghR/0iN/891f2w//AKXhXoHwtuv+CYHwt8d6F47/AGPP +CSPxAi/aN0L+0/+FdSfC3/gjj4//Y38dr/aej6ho/i7+wv2kP2qf2f/ANkj4C/DnPgXUPE6 6n/wnn7Qnw//AOEv0c6h4D8L/wDCV+M/FHh3wR4kAPr/AP4exf8ABLL/AKSWfsAf+Jkfs6// ADxqP+HsX/BLL/pJZ+wB/wCJkfs6/wDzxqP+GyP2iv8ApE7+3/8A+HG/4JZf/TLKP+GyP2iv +kTv7f8A/wCHG/4JZf8A0yygA/4eqf8ABOPUf9C8Aftn/s//AB38Wzf8gn4U/suePtL/AGsv jt4q8v8Ae3//AAg37P8A+zQ/xX+Nvj7+w9MS88R+Jv8AhCvAGv8A/CK+DtH8Q+NfEf8AZfhL w5r2tacf8PLP2df+ic/t/wD/AIqd/wCCpv8A9BvR/wANcftRav8A8Srw7/wSw/a/0TxBqf8A xL9C1n4s/GP/AIJ2+F/hZpGsXv8Ao2man8S/E3wt/ba+OPxN8O/D+wvZYLrxlrvw6+Cnxg8d 6R4ci1LUPCPwt+IHiC30/wAJ6uf8LG/4Km/9Gb/sAf8Aiyz9or/6U7QAf8PLP2df+ic/t/8A /ip3/gqb/wDQb0f8PE/h14g/4lHwn/Zy/b/+LfxAu/8AkAfD3/hgf9qf9nf/AISD7P8A6Vqv /F4v21vhp+y/+zL4P/srRYdS1v8A4uX8dPA//CQf2b/wi3g3/hJviBrfhTwf4gP+Fjf8FTf+ jN/2AP8AxZZ+0V/9Kdo/4WN/wVN/6M3/AGAP/Fln7RX/ANKdoAP+GyP2iv8ApE7+3/8A+HG/ 4JZf/TLKP+GyP2iv+kTv7f8A/wCHG/4JZf8A0yyj/hXP/BU3/o8j9gD/AMVp/tFf/TYqP+Fc /wDBU3/o8j9gD/xWn+0V/wDTYqAPkD4yn9tP9uTwd8bvgx8Qv+CYP/Cv7K3+ICeKv2Uvi9+0 V+0d+zF8H/EfwM0eL4E+EvClh8bfhx8VP2d9Z/4KaeOvh1+3/wDDL49eLfjF4n+Afjnwf8BP C/gTwj8LLLwz4juvivonxN0y48GePfn/AP4JNftD/wDBRLxV+z/8cfAXhn4C/sAfFf4gfAb9 v/8A4KF/C39o7X4P2zv2ovgho+nftHa5+1/8XPjl8StC8I+BNX/4Jy/GXyPh/B/wuXRtS+HW p23xb8fXWo+BNV8OyeLNQ0D4gJ4v8EeFfoDxn4l/a/8A2S/B37Y/7Rvxi/4Ky/sAWXwy8CfE DSvHHx0ufH/7Cv7QHi3w5+zVrFv8CfgP4Z0j4OeCvCeif8FV7nxB4I/4Tfw/bfD74q+HPgta 2Gt+O/iH8U/2gL3xJ4P0rWL34weFtGn+IP2Jv2U/2kf2Wvj7oXwY+On7f/xg/ZQ+Mn/BVbw/ 8b/+Cjuu/Bn4AeGv2Fj4V0j9vOXxpo/if9uj4JeHH/aQ+BP7V/inWvD/AMP/AIU/FX9mLSPg jpnw6+LPxOfxlp3wG/ay+MPiq78H+G18I6ddgH6P+Mv28f2v/h/8dvhP+y/4u+D3/BMDSP2j fjj/AGlP8Lfgb/w9L/aAv/in4o0fSPB3xL8d6h4u/wCEI0z/AIJP3viDRPh/b+H/AIP/ABFT /hYviKx0jwJL4j8O/wDCFweIpfGer6FoGp/P/wC1BoX/AAUS/ax/an/Yx/Ze+Iun/sgfsm+H /C3/AAs//goJp9z4N+KX7UX7a3hz4xeO/wBib4i/sz+Gfhb8Pviz4T0LTP8Agl3e6X8P/B3x N/ad8I/tA6boc/i74paP4x+KfwW+Gk/iLRNJ8P8AhTU9G8d/jDe/8GsP7XHhr/gqh8L/ANpZ /wDgox+0/wDFT4E+MfEHj63+I37UXhn46638L/8Agpd8GNOf4LfGTw58NYbn4seJ7bxzpHxL 8P6fpHh74M/AzxZ8QvDF5pPirxPpPj7WdE074A+A/hto1/4k0T7f8a/8ESf7O/b6/Zp+Fv8A w9z/AOC31/8A8Jj+yB+3D4//AOFi6l+3x9q+KfhX/hWvxo/4J7eHf+EK8G+Lv+FUJ/Yfw/8A H3/C1/7d+Jfhz+z7r/hKvEfw1+E+p/bbD/hDvI1EA/T/APaq+KP7fX7G/wCzj8aP2o/jX+29 +wBpHwy+B3w/1/x/4m8j/gnF8aLDWNd/si1P9jeCvCP/AAln/BYDwv4f1P4gfEDxBLpXgb4d eHNQ8Q6R/wAJX478ReHfDNrexXur22ef/Y2/Zw/4KvfDD9njwdY+If2k/wBiD4Y+NviL4g+K f7RvxR+Fvib9gz4wfEzUfhT8Zf2r/i346/ae+NHwqtviF4J/4KjeHfC3jTw/8M/it8XfGPgX wn4k0fS1g1bwroGjXkt/rFzLPrF+Wv8AwQc/Yb8R6d8FLz9onxd+2/8Ati/Fb9nzxBqviz4U /tB/tM/8FBf2xvEXxl8F+KtS8Vaf4rt/E3g7Ufh38Y/hn4J+HXiDR7nQPBtjp2s/C/wL4I1G eDwH4P1TWrnV/FOlSeIrr6f/AOHaf7Ov/RRv2/8A/wAWxf8ABU3/AOjIoA5/wn+yX+2EvhXw z4F1/wDbw8P/AAF8E/Dbw/o3hP4X+Dv+Cdn7FvwM/Z08K6X4V0rTrbR7Pwz4s8Pftfal/wAF HNIn8P8AhHSNH0LS/hho3wgs/gbp3hPTpPEtj4ltvH9tfeEIvAX4w/H/APZ8/wCCpPir9uL9 r3wN/wAEw/8Agq3/AGj+018Lv2f/APgm3pnxw8TftaeGv2MtW0fTvAnirxb/AMFO/FkXwt8T aN8Cf2AdR/4RX4geFf7R+F3xJ+Hmn3HgnwrrGo+BPjT4x1zxvrvi/RdR+DVt4V/b7/h2n+zr /wBFG/b/AP8AxbF/wVN/+jIr84P+CcX/AATX/wCCdX7SnhX42/t6+Ov2VfD/AO0Fbftp/GDU /FnwY1v9uvw18UP2pPiZpv7MHwY060+AH7P/AIm0rxf+3NN47+K0/h/9ofwt8Orz9rPw3rOq aL4T8QW/w9+Pvw/+EV9c+MfBPwV+GviOYA+IP+GN/wDg8k/6SxfsAf8AhufA3/0tOj/hgX/g 6a8W/wDJff21P2AP2gP7P/5FP/jI7/gop+x//wAIl9r/AOQ7/wAo0fBv7Dn/AAsT+3vs2jf8 lq/4Wh/wiX9i/wDFuP8AhCv+Em8ef8Jb+/3/AA6d/wCCWX/SNP8AYA/8Q3/Z1/8Anc0f8Onf +CWX/SNP9gD/AMQ3/Z1/+dzQB/KF+2Z+x/8A8FUfh/8ACzxF8JP2uf24/wDgkB+zd4f/AGiv h/8AE34daPc/HT/gtJ/wXh8J/wDCUaPqPhyLwz43n8LeE/2kP2vfEHwy+JH/AAjVl4z0iTW/ Dvi/wF8QvAkv9s6Rpvj3wjrvh/W5NG1P5/8AhPYftV/B/wCFnw0+Enh3/grz/wAEAbnw/wDC 74f+Dfh1oVz/AMRBH/BZzwh9o0fwT4c03wzpk/8Awifwt/bg+H/wy8L+bZaZBJ/wjvw68BeC fAmibv7N8I+EfDfh+20/RrL+734F/snfssfsv/8ACU/8M0fs0/s//s7/APCcf2J/wmv/AAov 4N/Dr4Sf8Jh/wjP9r/8ACN/8JT/wgHhzw/8A8JB/wj//AAkGvf2J/a32v+yv7b1f7B9n/tK8 873+gD+AP+2/jFrH/JWP2uf+DQL9qj7N/wAgD/huf/gor+3Z+33/AMIJ53/IV/4Vd/w2t+0P 8e/+FT/8JP5Wm/8ACbf8K0/4RT/hO/8AhHvCP/CZf27/AMIb4U/sf7f8J/8ABMn/AIKSePfC vhnx14F/4J8/8GcXjTwT408P6N4s8HeMfCf7KHx58R+FfFnhXxHp1trHh7xN4Z8Q6P4BvNI1 7w/rukXlnqmjazpd5dadqmnXVtfWNzPbTxSt/Y7XwB+z5/xbf9uL9t79n3wz+4+GV/8AD/8A Ze/bW0rQpP3Vr4M+Kf7VXi39qv4W/GvQPBGmaf8AYfD/AId+H/jDxB+yJo3x/wBY0q20V/Ef iD9o744/tIfFXxZ4r8RXvxMtdP8ADQB/JF+yv4N/4Lx/C39tr9sj4M/sOaJ/wTg+F3iT/gm1 4fstZ+Mf7GngD4w/t83P7Ev7Quo/t4eB9a/aX8EeE/gR8DPjz8WPEvwp+DHiDwx4p0TVtR8L XPwmT9iLwr4U8ceL9U8MeIPE3iH4N65r9lbe/wDxJ+L3/Bw78S/Cv/BL3/gqJD4M/wCCUC23 ifxB8FfCfwsk+Hfiv9uDwrP4e+Gf/BVLTvhj8KNF8M/tZ/DvVvippfhbx78H0+K3iz9m3xP4 r0b4fy/E74heBvjL8PPhh438EW2qeCfDXxBuNQ+oIvil47+B37bv/B4X8a/hbrv/AAi/xN+D /wCyB+xH8Uvh14m/szR9b/4R3x38P/8Agmp8a/FnhHXf7G8Rafq/h/V/7I8QaRp+of2Zrula no9/9n+y6np97ZSz20v6vftT/BTwr+zX/wAE+P2SP2c/AuoeINW8E/AH9p//AIIpfBTwdqni y606+8Val4V+Ff8AwUa/Yc8C+HtQ8TX2j6VoWkXniC80jQbO41m60vQ9G0641GS5msdK062e KzhAPmD/AI6mv+sAP/nRSvkD4zfsU/8AByP8cf2sf2L/ANsXxZr/APwRB074m/sL/wDDRf8A wqTQvDuq/t5WngTxF/w038NtL+Fvj3/hYumal4U1fxBq/wDZHh/SLa88I/8ACM+J/CP2DWHn uNZ/t+yaPT4v6vaKAPwB/wCOpr/rAD/50Uo/46mv+sAP/nRSv3+ooA/mh/aF+Nf/AAc4/s1/ AL44ftGeOtP/AOCEOreCfgD8H/iX8a/GOl+E7X/goHfeKtS8K/CvwXrXjrxDp/hmx1jVdB0i 88QXmkaFeW+jWuqa5o2nXGoyW0N9qunWzy3kJ+z18a/+DnH9pT4BfA/9ozwLp/8AwQh0nwT8 fvg/8NPjX4O0vxZa/wDBQOx8Vab4V+KngvRfHXh7T/E1jo+q69pFn4gs9I12zt9ZtdL1zWdO t9RjuYbHVdRtkivJv1f/AOCsX/KLL/gpZ/2YB+2R/wCs6/Eaj/gk7/yiy/4Jp/8AZgH7G/8A 6zr8OaAPgD/jqa/6wA/+dFKP+Opr/rAD/wCdFK/f6igD8gf+CN37FP7U/wCxd8LP2vv+Gxdf /Z/1/wCNv7WX7f8A8f8A9tbXf+GaNV+IuqfCzRf+F7+HPhf/AGnoGk/8LS8KeFfFunf2d4t8 K+J/sGlXn/CR/Y/Dk2g/aPFesanJqH2f9fqKKACvmD9kTRvg1oPwp8WWPwJ8WeIPGngmf9p/ 9t3Wdc1jxNbT2uo2fxl8R/tofH3xD+0Z4Ttorjwz4Tkbw/4C/aD1T4n+BfCdyul3UF54V8Oa NeWvibxpbTw+Mdd+n68A/Zp1v/hIPh14jv8A/hRf/DO/2f8AaA/ax0T/AIQD+yP7E/4SD/hG f2p/jJ4c/wCF6fY/+EW8H+d/w1B/ZX/DS/8Aa/8AZN3/AMJB/wALb/t7/hKfHH9pf8Jr4gAP f6KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigArwD9qP8AZv8AAn7W/wACfHPwB+IusfEDwv4f 8Z/8Izqen+NvhP431j4b/FP4c+O/h/4x8PfEn4W/FL4aeOdCkW98N/ED4XfE3wh4R+IXg3UJ 7fU9HHiPw1psPiLQvEHh+XU9D1D3+igD84PgR+3fqM/x90v9iT9r74aeIP2ev2sdW8P+P/EH wg1/WLPwrYfAL9uLwX8LfGninw14l+Jv7J+u6B8UPipc6T4gTwRo3hD42fET9lP4oeIrb4+/ ArwX8T9JgvD8VvB3hTXfi/d/zg/8Fz/+DebxV+3X/wAFaf2NP2gfhRpHiCx+Df7V/iDRPhx+ 3t4x8Pz6jFP8LoPgb4R/tiD4nL4h1CT4mR+HfEHxd/Z88F3HwW+GKx/CDSvg14b+Mvwx+HFp 8RPEDeJPj1BLc/1vftL/ALKv7OP7ZHws1b4KftR/Bf4f/HH4Zav9vn/4Rnx/oFrq/wDYWsX/ AIc17wn/AMJd4K1nEXiD4f8AxA0zw/4o8Q6f4c+IvgbVfDvjvwp/a97deGfEWkXsv2kfD8f7 Cn7bXwh8VeArr9lD/gqn8YNP+FPhnxB8W9Z8Q/AT9uv4K+B/27/Cuuad8QdR1LV/B3hPSvjd F4o/Zz/bQh8P/CfUfEOsv4bufiP+1L8WfFWpadpXw/8ADepeJh4W8KaxofjEA/T/AMJ+E/Cv gLwr4Z8C+BfDPh/wX4J8F+H9G8J+DvB3hPRtO8OeFfCfhXw5p1to/h7wz4Z8PaPbWekaD4f0 LSLOz0vRtG0uztdO0vTrW2sbG2gtoIol6CvgD/hXP/BU3/o8j9gD/wAVp/tFf/TYq8f+Cn/B PD9ofVvCuoeGv+CkP/BRT4wf8FC9Im8QXV/b/DXTfhF8JP2MPgFrPh+TTtKsIfDfxb+HP7Od jY+Nvj94f1G2k8c6B49+FXxl+L/jH9l/4qeC/GsehfET9nLxDq/hbQ/FCAGB+2Z/wvb/AIKF /wDCRfsMfs0f8UJ+yX47/wCFm/B/9vn9udv+EO1j+zvB2j+V4J+L/wCx3+yL4R8Q/wBsf8J3 +0B47/tjXvhd8U/2g9W8I6x8Cf2XP7H+Kvgmw1Px3+1p4E8QfC74Ue//AB0/4J6fCzxv/wAI t8Rf2ctT/wCGLv2rfg1+z/rf7OX7NH7SfwL8K+HIP+FQ/Cy8/si60H4UeKfgbfwR/BL47/s/ +HNT0HTZ9E+B3xX8I614c8B+fq/iL4Hal8GvincaT8TdD+3/AAn4T8K+AvCvhnwL4F8M+H/B fgnwX4f0bwn4O8HeE9G07w54V8J+FfDmnW2j+HvDPhnw9o9tZ6RoPh/QtIs7PS9G0bS7O107 S9OtbaxsbaC2giiXoKAPgD/hNf8Agqbo/wDxKP8Ahmn9gD4jf2V/xLf+Fhf8Nw/tFfBf/hO/ sP8Aov8AwmX/AAp3/h3t8e/+FT/8JP5X9t/8K0/4Xp8aP+EE+3f8It/wtj4jf2V/wmGseAfs 1ftK/wDBTXxb/wAFNfjd+zH+058Ef2QPA/7Mvgf9kD4bftCeH/EH7PfxJ+J/xb8d+EvHfxb+ J+vfDH4ceA/HnxH+J2g/An/hMf8AhMf+FE/tPeNGXwX+zDomj+EtH0TwJoeueO7jWrhW8W/r 9X5QftMfEnTv2Ef20NM/bb+NHjbw/wCHv2PP2lPg/wDAb9if4xeKLzwN4quJ/wBnH4y/DT4r fHrx7+zZ8ZviZ8TbHXJPBPgD9mD4k3P7RfxR+CfxS8a+NvDunwfDv4y6l+zJPP4kh8B+OfiR r3gEA/V+iiuf8WeLPCvgLwr4m8deOvE3h/wX4J8F+H9Z8WeMfGPizWdO8OeFfCfhXw5p1zrH iHxN4m8Q6xc2ekaD4f0LSLO81TWdZ1S8tdO0vTrW5vr65gtoJZVAOgor8oP2Q/8Agql4V/am +Mtl4K174PeIP2evhT+0H4f17xz/AME0vif8ZPFmneHfGn/BRH4Z/C2CJvjx8SfAPwJv9G03 xt8IfD/g621zwF8QfhfofxNvrb4hfHX4BePLL45+F/BOkeFvCnxCtfCP6f8AizxZ4V8BeFfE 3jrx14m8P+C/BPgvw/rPizxj4x8Wazp3hzwr4T8K+HNOudY8Q+JvE3iHWLmz0jQfD+haRZ3m qazrOqXlrp2l6da3N9fXMFtBLKoB0FFfnB4T/aw/a4+MXhXw18ff2ef2Rvg/8T/2T/H3h/Rv iT8LPEev/tda38Nv2oPi38GtW0621vRfG3gj4Aat+y7q3wb0bxB8VPDbr4s+Bvgb4vftefCm fUvD/iPwJbftDa5+zH4xv/iD4Q+GHQf8PIfgT4O/0T9pfwd+0B+xdqenf8jrqn7UfwS8Y+Ff gT8Nftn7zw5/wnP7cXgC3+JX/BPiw/4TG3utBt/DP9k/tZa19q8Y+KvD3whv/wCzvjbcXvw1 sAD7/r4A/bn/AGsvin8D/wDhV3wF/ZW+EP8AwvP9tr9qD/hNrD9n/wAI+JrfxHpXwJ+HPhz4 e/8ACIwfFb9pf9qP4i6LaP8A8IZ+z/8AAz/hYXgWbxDoOh3b/FP4w+MfGHgb4P8Awl0mbxL4 zl8ReFef8Wf8FKfhn4l8K+Jj+xd8NfjB+3p8SZ/D+s3PwZsvgR8N/iFa/swfGfxVpunXNy+j aX/wUT8T+C7P9g/QvD+hX9nqek+P/EzfHjWtR8MeIPDnin4baH4T8afHbTNO+Dut+gfsifBT 4++GvFXx3/aJ/a61D4P3n7SPx58QaF4YtfD3wIuvGmq/DP4MfswfBzUfG8v7O/wE0vxj400r wXq/xd8QeHdX+Jnxh+Lvj/4z618LPhr4g8T/ABC+OXinwZZ+HLH4XfDj4VaPogB8gfsYfse/ D3xN8b/2wPGn7TPxI8QftkftB/Cv9t/RvGfjQ/ET4OfDP4b/ALL/AML/ANpWb9mr9lT4k/DH 4qfsmfAfStV+IuuaB4g+Gf7Lmsfst/BXwp8Xvjh8Tvir8b/A/iD4W/E/Vfhh4r8Cx/G341at 8Yft/wDbW/ZN/wCGufhZoHh3w58XviB+zv8AG34SfEDSvjd+zR+0P8NLj7R4j+Cnx28M+HPF fhTQfFupeC7+7t/CXxb+H+t+EvHHjX4dfFj4NeP4Lvwd8UPhZ448ZeEb19E1PUtJ8U6B6/8A DTWfjLqnjT9oWx+J/hPw/wCHPBPhz4waLo37OesaNcwT6j49+DU/wC+B/iHXPFniyKHxNrsl n4gs/wBoPXvjt4Ftra60vwXO3hXwX4ZvF8M3VtdW/jHxZ7BQB8Afsjftrf8AC2fHfi/9kb9o PQP+FP8A7fXwE+H/AIC8TfGv4W3Glf2D4E+LvhzW9H0jTNV/aj/Y61C68V+L734o/sgeJPia 3iHwh4Y8Q6nq9v8AFP4a6xYWfgL9obwN8MfiLe6foWqfzBfHT/g26/4WV/wcc+Fvj7deAv7W /wCCfHxX/tv9vH4xf2vpv9ueDr/47eEPFGkf8LB/Zs1v/hMIvjFpniz/AIXZ8bfEXg/41eKf CfxB0b4XeDvGPwJ8ffHT4cfB1kuPgtdfZf63f2mf2L/2YP2w9O8HWf7RPwg8P+PdX+GniDTv Fnwp+INre+IPA3xl+DfirS/FXg/xrb+Jvgp8cvh3rHhL4yfBrxBceJPAHg2+1XWfhf468J6j rkHh7T9L1q51DSFksZPH/wDhkv8AaY8Cf6d8Ef8Agox+0B/xIv8AQ/AHwt/aj+Gn7Pf7SfwJ 0fw5/wAgyy8OeOdQ8OfDX4CfttfFj/hGPDUrxeGfGvi39un/AIWnrHjHS/D3jP4y+P8A4xf8 VroXjsA+/wCivgD/AIVz/wAFTf8Ao8j9gD/xWn+0V/8ATYq5/wATf8E0vh78atOtvD37aH7Q H7T/AO3b4J0vxB4T8TaJ8Lvj94v+Gfw8+DQ1Hwj4q0bxtbW3xC+C/wCxv8I/2VvhT+0d4fv/ ABT4V8GaxN4T/ar8HfHXwro0/hWCLwdo3hi28TeP4PGAB8gfE74naj/wWb1Hw/8As7/s7+H/ AIwQ/wDBMKH4wfEfw5+2j+2j4c+I/hX4UfD39sj4e/Cjwq2h6n+yb+ybqeht4l+OPxY+D/xY +OPiW18F/H/4/wDgu2+B/wAM9d+GfwP+N3wq+FXxu+IK/EFmX9vvCfhPwr4C8K+GfAvgXwz4 f8F+CfBfh/RvCfg7wd4T0bTvDnhXwn4V8OadbaP4e8M+GfD2j21npGg+H9C0izs9L0bRtLs7 XTtL061trGxtoLaCKJTwn4T8K+AvCvhnwL4F8M+H/BfgnwX4f0bwn4O8HeE9G07w54V8J+Ff DmnW2j+HvDPhnw9o9tZ6RoPh/QtIs7PS9G0bS7O107S9OtbaxsbaC2giiXoKACiiigAooooA K+APhz/ylN/bI/7MA/4Jp/8ArRX/AAVir7/r4A+HP/KU39sj/swD/gmn/wCtFf8ABWKgD8Af in/ycV/werf9mAfsq/8ArrL4+V+/3/BSz/k3X4c/9n//APBJ3/16b+xvX4A/FP8A5OK/4PVv +zAP2Vf/AF1l8fK/f7/gpZ/ybr8Of+z/AP8A4JO/+vTf2N6APv8AooooAKKKKAPgD/grF/yi y/4KWf8AZgH7ZH/rOvxGo/4JO/8AKLL/AIJp/wDZgH7G/wD6zr8OaP8AgrF/yiy/4KWf9mAf tkf+s6/Eaj/gk7/yiy/4Jp/9mAfsb/8ArOvw5oA+/wCiiigAooooAK8f+B+jfGXQfBetWPx2 8WeH/Gnjaf4wftC6zoeseGbaC106z+DXiP4+/EvxD+zn4TuYrfwz4TjbxB4C/Z81T4YeBfFl y2l3U954q8OazeXXibxpczzeMdd9gr5g/ZE0b4NaD8KfFlj8CfFniDxp4Jn/AGn/ANt3Wdc1 jxNbT2uo2fxl8R/tofH3xD+0Z4Ttorjwz4Tkbw/4C/aD1T4n+BfCdyul3UF54V8OaNeWvibx pbTw+MddAPp+iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK+AP8AgoR+2h4x/Yu8HfAfV/AH wT/4Xv4t+O/7QCfAvSfC32747R/2L5fwJ+Ovx0v/ABT/AGJ+zR+y7+2J8bfFn2bTPgfeaJ/Y ngr4F6/9j/t7/hKfEmr+HPCXhzXtXt/v+vAP2hP2YvhF+1Bo/gPRvi3afED/AItf8QF+KXw9 8QfC342fGz9n/wAd+D/Hf/CCeO/hjNruhfEf4A/EL4ZfECy+2/D/AOJvjzwnqemR+Jv7H1XR /E2oW2pafd/6O0IB+cHhT/gsh4V1jxB8O9P1z9mn4waV4W8e/B/4n6xoXxAtbnTtL074mftP /Cz9qD9kz9iXX/2T/gp8Ofi/Z/Bn4/af4gt/2vv2oV/Z+1X4ifto/B39h7w/oHirwnp/ivU9 JX4U+IPEvxC+HXr/AOxh/wAFbf2WP23fjZ8Tf2aPANt8QPh5+0b8F/8AhbVn8Vvgj8Uofh1/ wnfgPxH8Bvi7bfBr4weHNdT4W/En4peH1/4RDxB4k+F+raZ41stevPhZ8TtH+Ken2Hwb8f8A xF8Z/Cn9pLwl8Dz4hf8ABK39n+Xw54wvvglpv/CIfGDWfh/dfDvwj4y+OnxH/a//AGivh18P 7XxJ8U/g78YfiL8QPC3wng/a7+El74Q/aA8ffE34I+Bvjfrf7T3wo+I3wt/aO1P9qfQtI/am 8VfFTxZ8YF8Ra34o9A/Yd/4J3/CL9h/w5HJ4P174geJPib4k/wCFla98YvGV58UfjY3g74sf En4yfFPVPjD8QfiT4k+E/jD4s/EDw/4o+IEXiDU7XwF4K+N3xi1L4yftY6f8CfCHgD4SfEL9 pX4o2Xhu61vWQD5A+JH/AAWVtfhJ+3t8Xv2UvHvwH/sr4JfAT/hZ/iD4vftG6fq37R3ifWPA /wAIvgv+wf8AD/8AbW+Knx11PwP4U/Y21v4JXHw/8D6n8W/hJ8BNd8Nab+1lffGy38d/Fj4W 6tH8JJdM+I3gy11v1++/4K5fCTS/jf8ABD9lzUv2eP2n7L9qP44eIP2pvA1j8AZLH9nibxV4 C+Jn7LH7NXw5/a31T4bePfHNn+0Xc/A5vEHxc+B3xj+EfiT4Sa54D+LHjr4epqPxB03w58Wv G3wo1zw/46svCf2B4s/Yv/Zg8e634m1/x18IPD/jS58afGDWfjv4x03xZe+IPEfhXxZ8TPEf 7I9z+wj4h1TxN4J1jWLzwdr3h/Xf2Try8+EGs+ANU0K6+HuqaddXPiW+8LT+N55fEzc/4P8A 2Cv2TvBHiP4O+OdM+FP9tfE34DfED4hfFL4b/GX4heOviT8VvjtbeO/ir8LLr4H/ABA13xh8 dvif4x8X/GD4pf8ACSfB9tC+G11pnxS8beMtHtvB3w8+Duh6fp9nZfBL4QxeCQD4A/Z7/wCC 8H7LHxm+Cfjzx/4p8G/ED4a/GD4N/sAN/wAFC/jH+zjBqvw68feO9C+Fml/CLwJ8cfEOmeEd S0LxlZWWt/aPhl8YPgR41+HXirx/ZfCbw58StH+N/h3w5pc+m/GD4RftbfCj9mv9nvCes6j4 j8K+GfEOseE/EHgLV9e8P6NrOqeBfFlz4VvPFXgvUdU062vr7wn4mvPAvibxp4JuvEHhy5nl 0fWbnwd4x8WeFZ9Rs7mXw94m13SGs9UuviDwB/wS/wD2LPhh8LPGvwP8FfDr4gaZ8H/iR+z/ AOI/2YvH/wANr39pL9p3xB4O8ZfCLxR4cs/A15aeJND8R/GPV7LV/iBpHwy0jw58GvBXxsvY pfjZ8O/gT4M8AfAnwB8QvDXwf+H/AIK8E6D9/wBABRRRQB+cFz/wTS+HvgvxVo3iX9kj9oD9 p/8AYG0jS/D/AIm8M3Hwe/ZT8X/DNv2YLrTvE2o+E9amufD/AOyL+0Z8I/2hf2XPhB4gstc8 L3uvnxZ8AfhB8JfFXiPxB49+Juu+OdZ8Wav461y8n6D/AIdl/sneKP3/AO0F4e+IH7Zl7d/8 TPXbH9tb4u/En9p74Wan47uPn1P4paB+y/8AFLxJrf7Ivwf+IF7Nca1DpWofAD4A/CXR/h/4 c8U+K/h78KtC8B/DLxBqHguX7/ooA8f+Nf7PXwC/aU8K6f4F/aM+B3wf+P3gnSfEFr4s0vwd 8a/hp4L+KnhXTfFVjp2q6PY+JtP8PeOtF17SLPxBZ6RruuaXa6zb2ceo2+nazqtjDcpbajeR TeAeE/8AgnJ+x74a8VeGfHWv/DLxB8dPG3gLxBo3iz4X+Mf2u/jN8c/22PFXwY8VaFqNtrFn 4m+BHiH9r74lfG/V/gT4gutX07QtU13WfhBeeCtR8T6j4T8EX3iW51a58DeEJdE+36KACiii gAooooA8A+Deif2V8Rf2sb//AIXp/wALb/4Sb9oDw5rf/CAf2v8A2l/wy/8AZ/2WP2afDn/C i/sf/CU+IP8AhH/+Eg/4R/8A4aX/ALI/snwP53/DRH9vf8Itd/23/wAJr4w/ID45/wDBc7/h S/7dnxB/Yp/4Zd/4SX/hBP2//wDglx+wx/wsv/hdv9j/ANq/8PKPg78Tfiz/AMLR/wCEN/4V Hqv2H/hS/wDwrr+wP+EJ/wCErvP+Fjf2x/av/CXeBP7P/s2+/V/4Baz8GtU+K37btj8MPCfi Dw5428OftP8AhPRv2jNY1m5nn07x78ZZ/wBi/wDZE8Q6H4s8JxTeJtdjs/D9n+z5r3wJ8C3N ta6X4LgbxV4L8TXjeGbq5urjxj4s8/8AGX/BN79iX4g/GXW/2g/GPwD8P658ZPEfxg+D3x+1 vx1ceIfHEGo6h8Zf2e4PhPY/Az4hTWdn4ottIXxB8I9I+Dnh7w78PZotOjg8KeFfGnx+8KaP b2vhv9qP9pbS/iyAfEGpf8FzfgnbfFPwb4T0/wDZ8/aA1P4Za3+yB8S/+Cgni74t+b8IrL/h Cf2CfC/iP4T6b8Ov23v+ECn+JzeIPEn7P/xR8P8Ai/4peJv+Fe6Zcxft4eCf+FP/ANja7+xD cXvxA8OyWxP/AMF0P2cfBv8AwU/+PP8AwTF+NOgf8Kw8dfDv4gfslfDr4P8Ajn/hMrXXv+F2 6x+1N4A8Na5DP/whN34f8NXvh/8A4Qz4m/Ej4OfCL/hHfA+vfGHx3rX/AAs//hcmq+EfBvwF +FHx6+JPwq+n7n/gkn+wFdeKtG8Yy/BXxAur6F4f8TfD+xs7b48/tF2fhWf4GeLNR8J6pqn7 J+s+BbP4tQeCfEf7EFrc+C9Hi8M/sLeIfD2qfse+C9OvPFmj+DvgjoWkePfHVj4j9Ak/4Jyf sej9qDx7+2jp3wy8QeGv2o/ij4g+Emv/ABD+M3gn4zfHPwH4q8YQfBPw/pvhjwP4I1xPBnxK 0HSLz4P3mkaD4YX4k/A19MHwa+NWo+DvA2ufGbwJ4+1zwP4S1HRgD5g/4Klf8FRPGP8AwTt1 j4MeHfA37NX/AA0d4g+MHw/+N3jLS9Cg8U/HbRNYvvEfww8d/s0fC3wB8J/COmfAj9kb9rC9 v/iB8e/ib+074J+HXw61L4kwfCL4WQ+O7jw74R1z4l2XiDx34W0+7Pib/wAFq/2WPhN+yd8c v2xfFfgH9oA/DL4K/D/9mz442OhaZ4V+HV547+Mf7M/7YvxJuvhb+y/+0l8LdMf4q2/h+y+H /wAYPEGieM7zT/A/xe8T/Cf9oTwTo/gbXbj4qfBPwFe6n4L0/wAWff8A8av2XPgT+0R/bP8A wuLwN/wmH/CQfs//AB9/Zc1f/ipvGPh/7X8Cf2oP+Fcf8L08Df8AFLeIdE+z/wDCcf8ACpPh 9/xU1r5PjHwz/wAI/wD8Uf4h8P8A9q63/aXj91/wTe/Yl1L4NfGv9nzXPgH4f8T/AAb/AGgf D+leDPiN4F8X+IfHHjDTofh74Vn1C++Gvwr+Gt54o8Uatq/wO+D/AMDtX1bV/EX7OPwh+CWo /Dz4Z/s1+KtY1fxX8BPCnw58Sapf6pcAHzBH/wAFjvgn4R/ax8b/ALJP7QXwx+IH7Pfi2P8A a/0f9kb4GeJvF3ij4ReI9H+Pmsaz8Nv2b/Flt4v8O6N4N+IWseLdL87xb+1l+zt4eg8BWehe J/Hdv4E+O/w6+MevaRoHhL4dftq237HP3/8As6/tCaP+0j4c+I/izw54D+IHgrw/8P8A9oD4 +fs92WoeP18CRf8ACwtY/Zy+Kfib4KeP/Hngq18FeO/G17bfD+5+Jvgnxr4Z8ON4/tvAvjvU f+EXvdZvPAmmeH9T8Oarrfn97+wj+zPd/HbxH+0vD4X+IGifG3xd8QPBXxL8ReNfCXx//aE8 Ff2l4j8D+DvAHgCDTX8OeEfinonhK3+H/jjwl8JPg/pPxu+E9poNv8LP2iP+FNfBq/8Aj14N +JGp/CT4dXvhn3/4afC3wJ8H/DmpeE/h1oX/AAjvh/V/iB8WfilqGn/2nrGr/aPHfxx+KfjL 41/FLXftWu6hqd7F/wAJR8TfiB4u8Tf2ZBcxaPon9r/2N4d0/SPD9hpmlWQB6BRRRQAUUUUA FfzQ/Fb/AIKy+Ff2cP8AgsD+354F8PfsN/8ABR/9rTV/h1+zB/wTv+Cnjq4/Yx/Zn0748ad4 R8VaPe/th/tGWeoeJZrH4j6Hc6B4f8U+Cf2q/B2l+ErrWLOx1HW/FXgb4qWMWlRaR4Z0vXPE X9L1fhDqX/BPH9mD4+/8FC/+Cw3wi+O3hXxB8VvhT+29+zB/wSS+Nfxv8Baz4x8QeFtOk8Vf DDx9+2j8MvCGn+E9e+Gd34F8beH/AA/ZW37LHww8VXNq3iq/1G+8VSeJhdarJ4W1a38L6cAf zw/GD9uD4p6J4t/4OO/jp4s/4JV/8Ff/AAN8Mv8Agpj+yB8LvAHwk8U+N/2HPEfhnR/g/wD8 KV/Yd+K/wL8eeNf2kNb1LxbF4f8Ah/8AD/TPEHii28UyeI/DOr+PfsXgTTdY1vWbLSr2zj0i 4/b7xH/wVT+Fn/BRL4YfFD4W+E/2dv2v/wBmf4m/sn/t/wD/AAQ5/wCFt/Dr9sX4R+HPgz47 sf8Ahev/AAU1/Zr8ReAvsfhHTfiH428QW32nw/4JudduP+Em0/w552j694Y1PRv7XstUkntP wB8ff8EZv+CbGifGj/g6A8J6Z+zf9m8P/wDBO39kD4AfFL9jrT/+FwfHqb/hT/jvxt+wL8Xf jX4n137VcfFGW9+IH9p/E3wvoXib+zPilc+NtHsvsP8AY2n6faeH7m80q4/p+/bG/Yp+FnwO 8T/tFfti+E9f+IGo/E39uj9v/wD4IJf8Lb0LxFqvhy78CeHf+GZP+Cgn7Jfwt8Bf8K60zTfC mkeINI/tfw/q9zeeLv8AhJvE/i77frCQXGjf2BZLJp8oB+31FFFABXyB8Uv26P2f/hJ47134 bazB+0B478W+FP7Mg8Y237Pf7Hf7X/7VGj+B9Y1jR9P8Tad4R8eeLP2ZvgX8W/CXgf4gXHhL W/DPjZvh14s1zR/Hdv4E8ZeBPHNz4dh8JeO/B+s639f18Af8E0/+TdfiN/2f/wD8FYv/AF6b +2RQB8gf8FCf22vhh8cf2Bf24fgp8Lfg5+3/AOKPib8YP2QP2lvhb8OvDP8Aw6w/4Ka6J/wk Xjv4gfBfxr4T8I6F/bPiL9kfSPD+kf2v4g1fT9P/ALT13VdM0ew+0fatT1Cysop7mI/4J7ft tfDD4HfsC/sPfBT4pfBz9v8A8L/E34P/ALIH7NPwt+Ivhn/h1h/wU11v/hHfHfw/+C/grwn4 u0L+2fDv7I+r+H9X/sjxBpGoaf8A2noWq6no9/8AZ/tWmahe2UsFzL+31FAHyB8Lf26P2f8A 4t+O9C+G2jQftAeBPFviv+04PB1t+0J+x3+1/wDsr6P441jR9H1DxNqPhHwH4s/aZ+Bfwk8J eOPiBb+EtE8TeNl+HXhPXNY8d3HgTwb478c23h2bwl4E8Yazon1/XwB/wUs/5N1+HP8A2f8A /wDBJ3/16b+xvX3/AEAFFFFABXgH7NOt/wDCQfDrxHf/APCi/wDhnf7P+0B+1jon/CAf2R/Y n/CQf8Iz+1P8ZPDn/C9Psf8Awi3g/wA7/hqD+yv+Gl/7X/sm7/4SD/hbf9vf8JT44/tL/hNf EHv9eP8AwP0b4y6D4L1qx+O3izw/408bT/GD9oXWdD1jwzbQWunWfwa8R/H34l+If2c/CdzF b+GfCcbeIPAX7PmqfDDwL4suW0u6nvPFXhzWby68TeNLmebxjroB7BRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAeP8Aw01n 4y6p40/aFsfif4T8P+HPBPhz4waLo37OesaNcwT6j49+DU/wC+B/iHXPFniyKHxNrsln4gs/ 2g9e+O3gW2trrS/Bc7eFfBfhm8XwzdW11b+MfFnsFeAfBvRP7K+Iv7WN/wD8L0/4W3/wk37Q HhzW/wDhAP7X/tL/AIZf+z/ssfs0+HP+FF/Y/wDhKfEH/CP/APCQf8I//wANL/2R/ZPgfzv+ GiP7e/4Ra7/tv/hNfGHv9ABRRRQAUUUUAFFFFABRRRQAUUUUAFfAHw5/5Sm/tkf9mAf8E0// AFor/grFXP8A7T/hPwr8eP20P2Wf2V/jR4Z8P/FH9m7xp+zB+2v8d/HnwP8AHOjad4j+GfxF +JnwP+K37BfgT4S6p8SfCWpW0+kfEXw/4E0j9of4o6zofgDxtba98PYviFdeCfivP4Wn+KPw k+EfjDwN8geAf+CZP/BNu8/4KSftX+Bbz/gnz+xBdeCfDn7EH/BPnxZ4e8HXP7KHwGn8K6F4 q8afHn/gpto/jHxNo3h6XwC2kaX4g8WaR4C8C6X4m1mxs4NR17TvBfhOx1S5urbw5o8VmAfn B8U/+Tiv+D1b/swD9lX/ANdZfHyv3+/4KWf8m6/Dn/s//wD4JO/+vTf2N6+IP+Cm3/BMn/gm 34C/4Jt/8FBvHXgX/gnz+xB4L8beC/2IP2r/ABZ4O8Y+E/2UPgN4c8VeE/FXhz4DePtY8PeJ vDPiHR/ANnq+g+INC1ezs9U0bWdLvLXUdL1G1tr6xuYLmCKVT/goN/wTJ/4Jt+C/gN4B1jwd /wAE+f2IPCer3n7b/wDwTJ8J3mqeGf2UPgNoOo3XhXx7/wAFJP2UPAvjrwzc32l+AbW5n8P+ NPBPiPxD4O8WaNLK2neI/Cuu6z4e1i2vNI1S+s5wD93qK+IP+CeXizxV4s/Zuv4vFvibxB4u ufh5+0/+3h8CPDWt+LNZ1HxP4qb4Z/s4ft0/tG/AD4QaX4m8X67c6h4p8c+IPD3wp+Gngzw9 rPj/AMcax4i+IXj3UdLufGPxD8U+KvG2t6/4j1T7foAK+AP+CcH/ABLvgv8AGrwfqH+geLfB 37f/APwUt/4S7wte/wCi+I/Cv/Cyv2+v2ivjp8Ov+Ek0SfZqeh/8J98Eviv8LfjF4K/tO1tf +Eq+FnxK8AfELQvt/hLxj4d1fUfv+vmD41/sRfsX/tKeKtP8dftGfsifswfH7xtpPh+18J6X 4x+NfwC+FPxU8Vab4VsdR1XWLHwzp/iHx14T17V7Pw/Z6vruuapa6Nb3kenW+o6zqt9DbJc6 jeSzAH0/RXwB/wAOnf8Agll/0jT/AGAP/EN/2df/AJ3NH/Dp3/gll/0jT/YA/wDEN/2df/nc 0AH/AAUf/wCJj8F/gr4P0/8A0/xb4x/b/wD+CaX/AAiPhaz/ANK8R+Kv+Fa/t9fs6/HT4i/8 I5okG/U9c/4QH4JfCj4pfGLxr/Zlrdf8Ir8LPhr4/wDiFrv2Dwl4O8Ravp33/XzB8FP2Iv2L /wBmvxVqHjr9nP8AZE/Zg+APjbVvD914T1Txj8FPgF8KfhX4q1LwrfajpWsX3hnUPEPgXwno Or3nh+81fQtD1S60a4vJNOuNR0bSr6a2e506zlh+n6ACiiigAr5g/ZE0b4NaD8KfFlj8CfFn iDxp4Jn/AGn/ANt3Wdc1jxNbT2uo2fxl8R/tofH3xD+0Z4Ttorjwz4Tkbw/4C/aD1T4n+BfC dyul3UF54V8OaNeWvibxpbTw+Mdd+n68A/Zp1v8A4SD4deI7/wD4UX/wzv8AZ/2gP2sdE/4Q D+yP7E/4SD/hGf2p/jJ4c/4Xp9j/AOEW8H+d/wANQf2V/wANL/2v/ZN3/wAJB/wtv+3v+Ep8 cf2l/wAJr4gAPf6KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigD5g+AWs/BrVPit+27Y/DDwn4g8OeNvDn7T/hPRv2jNY1m5nn 07x78ZZ/2L/2RPEOh+LPCcU3ibXY7Pw/Z/s+a98CfAtzbWul+C4G8VeC/E143hm6ubq48Y+L Pp+vH/hprPxl1Txp+0LY/E/wn4f8OeCfDnxg0XRv2c9Y0a5gn1Hx78Gp/gF8D/EOueLPFkUP ibXZLPxBZ/tB698dvAttbXWl+C528K+C/DN4vhm6trq38Y+LPYKACiiigAooooAKKKKACiii gAooooA+APiN/wApTf2N/wDswD/gpZ/60V/wSdr+fX/gn/8A8EBf+Gc/+C0/x1+LnijwVu/Z B/Zz/s/4y/sf/wBtaf8A2noPirxX8ZJdd/4V54csv+Eqj+KP/CRf8Mmf2V480nU9Y17x94S+ M+mfEnwr+z38bYdLh8PeOrLzvuv4lf8ABVP9hb9o39ofwX8Ez4j/AGn/ANk/47eAf2n/APgp T+yf4T/bM0aw/Zu8Had8EtR/4J9fCT4b/GT9szVvFniz4r+I/it8O7/9mD4n/DvVvCs1to/x d+Dnj7wrqfirwH4Z+Knir4d/C74k/Bf4N/Ffwb8wfGH/AIKdfB34K+BP2pfGvin/AIKbf8Fv or39k/8AsS88X+APEX7AX7CfwZ8d+OfDmp6x+yF4c1fxH8OrP9o7/glv8F/D8n/CF+IP23vg RZeLvBXj/wAR/D/4p2ej69B4/wBL8Aav8MvFHw18a+PQD+p3xZ4Z07xp4V8TeDtYufEFnpHi zw/rPhnVLzwn4s8VeAvFVrp2u6dc6XfXPhnx14F1nw5428F+IILa6ll0bxZ4O8Q6F4q8Oait trHh7WdL1ezs76D8Af2SP2ef20P2kviZo/wF/bo/aD8P+MfgT/wSD+MHwi+GVtafB3xD8VtM 8cf8FDP2n/hf8Pfg1+05+zv+1J+2F4i8aanf+KdJ8P8Awp+FPxP/AGefHeq/s+6F498feH/i b+21YfEj4o/EXx14l+G3gP4VeCdTw9d+OPwK+LHwx/4KW6bo/wDwWI/4KB/tB6N/wTn8B/F2 x/bs+DcP7L//AATbaWx0zwf4f+MUHjn4ZRad8Y/+CWHgj4a/FWTxRa/Bv4oeFUstJ8T6x4G1 hrAQa3r1noGuWGoXv4ef8Epf2Of2T/2efjt+0N+1Rr37e3iT9mn4XaV8XPjd8Of2HP2nPAM3 7Lfxf0i0/Zt8GfG742/s+3n7Qf7RXxr+Lf7KP7Rf7Lf7MfhP9ovxH8Mp/hH+zB8XPF/iT9n3 X/2kfFHhf47/AA7+EVr4i0HXo9A8QgH9f3/BNP8A5N1+I3/Z/wD/AMFYv/Xpv7ZFff8AXwB+ wr+0h+yd8U/Dml/Cr9kXR/iBB8MtB/Z/+Dn7T3hbxZ418EfEnwb/AMLF8CftVfFP9pzRtE+I l7c/HSPSfj145+IHxL8dfs+fFP4s+P8A4qfFXw4+sfGj/hYnhv43L8QPife/EzV/Ew+/6ACi iigAooooAKKKKACiiigArx/4H6N8ZdB8F61Y/HbxZ4f8aeNp/jB+0LrOh6x4ZtoLXTrP4NeI /j78S/EP7OfhO5it/DPhONvEHgL9nzVPhh4F8WXLaXdT3nirw5rN5deJvGlzPN4x132CvmD9 kTRvg1oPwp8WWPwJ8WeIPGngmf8Aaf8A23dZ1zWPE1tPa6jZ/GXxH+2h8ffEP7RnhO2iuPDP hORvD/gL9oPVPif4F8J3K6XdQXnhXw5o15a+JvGltPD4x10A+n6KKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD5A+Dfj34WaV +0x+1j8Gv+Gv/h/8W/jb4m+IHhz46f8ADL3/AAsnw5qXxT/Zf+Flv+z3+zT8LP8AhFv+FY/8 J14g8W+H/h/4g8W+H/8Ahd39t/8ACJeB/Dk3iP8AaI3/ANkXep63/wAJZ4w6DRv23f2L/Efw a8WftGeHv2u/2YNd/Z88BeILbwn46+O2jfH34U6p8GvBfiq8n8M2tn4Z8WfE+x8WT+CfDniC 6ufGng63ttG1jXLPUZ5/FnhmGK2aTXtLW6+n6KAPANb/AGsf2WPDP/Ci/wDhI/2lv2f/AA// AMNQf2R/wzR/bfxk+HWlf8NEf8JB/wAIt/YP/Ci/t/iO3/4W3/bf/CceCv7I/wCEA/4SD+0v +Ew8LfY/O/4SDSfte/o37QvwC8R/GXxZ+zn4e+OPwf139oPwF4ftvFnjr4E6N8S/BeqfGXwX 4VvIPDN1Z+JvFnwwsdan8beHPD91beNPB1xbazrGh2enTweLPDM0Vy0evaW117BRQB8waN+2 7+xf4j+DXiz9ozw9+13+zBrv7PngLxBbeE/HXx20b4+/CnVPg14L8VXk/hm1s/DPiz4n2Piy fwT4c8QXVz408HW9to2sa5Z6jPP4s8MwxWzSa9pa3XQa3+1j+yx4Z/4UX/wkf7S37P8A4f8A +GoP7I/4Zo/tv4yfDrSv+GiP+Eg/4Rb+wf8AhRf2/wAR2/8Awtv+2/8AhOPBX9kf8IB/wkH9 pf8ACYeFvsfnf8JBpP2v3+igDx/Rv2hfgF4j+Mviz9nPw98cfg/rv7QfgLw/beLPHXwJ0b4l +C9U+MvgvwreQeGbqz8TeLPhhY61P428OeH7q28aeDri21nWNDs9Ong8WeGZorlo9e0trrgN G/bd/Yv8R/BrxZ+0Z4e/a7/Zg139nzwF4gtvCfjr47aN8ffhTqnwa8F+Kryfwza2fhnxZ8T7 HxZP4J8OeILq58aeDre20bWNcs9Rnn8WeGYYrZpNe0tbr6fooA8A1v8Aax/ZY8M/8KL/AOEj /aW/Z/8AD/8Aw1B/ZH/DNH9t/GT4daV/w0R/wkH/AAi39g/8KL+3+I7f/hbf9t/8Jx4K/sj/ AIQD/hIP7S/4TDwt9j87/hINJ+17+jftC/ALxH8ZfFn7Ofh744/B/Xf2g/AXh+28WeOvgTo3 xL8F6p8ZfBfhW8g8M3Vn4m8WfDCx1qfxt4c8P3Vt408HXFtrOsaHZ6dPB4s8MzRXLR69pbXX oHibxZ4V8F6dbax4x8TeH/CekXniDwn4Ts9U8Tazp2g6ddeKvHvirRvAvgXwzbX2qXNrbT+I PGnjbxH4e8HeE9GilbUfEfirXdG8PaPbXmr6pY2c54m8WeFfBenW2seMfE3h/wAJ6ReeIPCf hOz1TxNrOnaDp114q8e+KtG8C+BfDNtfapc2ttP4g8aeNvEfh7wd4T0aKVtR8R+Ktd0bw9o9 teavqljZzgHgGjftu/sX+I/g14s/aM8Pftd/swa7+z54C8QW3hPx18dtG+Pvwp1T4NeC/FV5 P4ZtbPwz4s+J9j4sn8E+HPEF1c+NPB1vbaNrGuWeozz+LPDMMVs0mvaWt10Gt/tY/sseGf8A hRf/AAkf7S37P/h//hqD+yP+GaP7b+Mnw60r/hoj/hIP+EW/sH/hRf2/xHb/APC2/wC2/wDh OPBX9kf8IB/wkH9pf8Jh4W+x+d/wkGk/a/f65/wn4s8K+PfCvhnx14F8TeH/ABp4J8aeH9G8 WeDvGPhPWdO8R+FfFnhXxHp1trHh7xN4Z8Q6Pc3mka94f13SLyz1TRtZ0u8utO1TTrq2vrG5 ntp4pWAPzA0D9jb/AII/a/8AtQeN/h5o/g79mDxt+1h4T8QfHL4/fFD4JXnxTsvHvxM0fUf2 s/D/AI70P9oj4hfEz4Cav461y5j8P/tCeCP2o4vCXxSm8Y+B28K/EX4et+zJ4M8Q2+qeDvgB +y1pHwz+YL/9iX/ggf8AGD4E/tEfHfxP8Y/h/wDHH9nLxz9n+Fv7SHx7+IX/AAVP/aI+NXws t9Yv/GP7KXiePQvGHxn8b/tceLfD/gT4gax4g/Z//Y60u61O38U+HfHet+HPAXwd8AXmoXng yXR/Dl7+33gr4sfCz4lfY/8AhXXxL+H/AI+/tH4f+APixp//AAhXjLw54q+3/Cz4r/8ACR/8 Kt+Jdn/YWpX/ANq+H/xK/wCEO8Xf8IB4yg3+HPGP/CK+I/8AhHdS1H+w9T+y+gUAfmBP4B/4 JgeA/Ani74W698bvh/p3wy/4K0f8LF/sP4dePf24/H+reBP2nv8AhpvWPEXiL4k/8MjeEfG3 x21Dw/4e/wCFzeIP2l73XdX/AOGQ9P8ACP8AwlOsfEzwhqcXn3reBp7Qn/Zp/wCCYHxG+Nni 79n3SfEfw/uP2jfBP/Cxfix8Tvgj8Nf2sfH/AIT+Nmn/APC4Pi74i/aVb4l/Fz4bfDj4yaJ4 61H/AIV78ev2kdY+P/7LvjL4iaLe/wDDJHxd+LOl/FX9k/Uvg54z1vw/rx+/5/ix8LLbwJ4u +KVz8S/h/b/DL4f/APCxf+E9+Is/jLw5F4E8E/8ACn9Y8ReHfi3/AMJd4uk1JfD/AIb/AOFX eIPCHizQviL/AGzqFl/whOseF/EWmeJv7MvdE1KC29AoA/OD4B+Ov+CXPwj+GfxC/at+Av7Q X7MFr8G9C8P/AA++BHxf/aT039qTwz45+GdtP4L+IXxD+JHhrS/i38Ytf+JviTwtc/GDxJ8V v2vvHvj3x74/8d+I5/jL8Y/iF8dI/FPxR8U+NfEniPQr5vqDW/2sf2WPDP8Awov/AISP9pb9 n/w//wANQf2R/wAM0f238ZPh1pX/AA0R/wAJB/wi39g/8KL+3+I7f/hbf9t/8Jx4K/sj/hAP +Eg/tL/hMPC32Pzv+Eg0n7X7/RQB4/o37QvwC8R/GXxZ+zn4e+OPwf139oPwF4ftvFnjr4E6 N8S/BeqfGXwX4VvIPDN1Z+JvFnwwsdan8beHPD91beNPB1xbazrGh2enTweLPDM0Vy0evaW1 1wGjftu/sX+I/g14s/aM8Pftd/swa7+z54C8QW3hPx18dtG+Pvwp1T4NeC/FV5P4ZtbPwz4s +J9j4sn8E+HPEF1c+NPB1vbaNrGuWeozz+LPDMMVs0mvaWt19P1z9t4s8K3nirWfAtn4m8P3 Xjbw54f8M+LPEPg621nTp/FWheFfGmo+LNH8HeJtZ8PRXLavpfh/xZq/gLx1pfhnWb6zg07X tR8F+LLHS7m6ufDmsRWYB5Brf7WP7LHhn/hRf/CR/tLfs/8Ah/8A4ag/sj/hmj+2/jJ8OtK/ 4aI/4SD/AIRb+wf+FF/b/Edv/wALb/tv/hOPBX9kf8IB/wAJB/aX/CYeFvsfnf8ACQaT9r39 G/aF+AXiP4y+LP2c/D3xx+D+u/tB+AvD9t4s8dfAnRviX4L1T4y+C/Ct5B4ZurPxN4s+GFjr U/jbw54furbxp4OuLbWdY0Oz06eDxZ4ZmiuWj17S2uvYKKAPmDRv23f2L/Efwa8WftGeHv2u /wBmDXf2fPAXiC28J+Ovjto3x9+FOqfBrwX4qvJ/DNrZ+GfFnxPsfFk/gnw54gurnxp4Ot7b RtY1yz1GefxZ4Zhitmk17S1uug1v9rH9ljwz/wAKL/4SP9pb9n/w/wD8NQf2R/wzR/bfxk+H Wlf8NEf8JB/wi39g/wDCi/t/iO3/AOFt/wBt/wDCceCv7I/4QD/hIP7S/wCEw8LfY/O/4SDS ftfv9FAHj+jftC/ALxH8ZfFn7Ofh744/B/Xf2g/AXh+28WeOvgTo3xL8F6p8ZfBfhW8g8M3V n4m8WfDCx1qfxt4c8P3Vt408HXFtrOsaHZ6dPB4s8MzRXLR69pbXXAaN+27+xf4j+DXiz9oz w9+13+zBrv7PngLxBbeE/HXx20b4+/CnVPg14L8VXk/hm1s/DPiz4n2PiyfwT4c8QXVz408H W9to2sa5Z6jPP4s8MwxWzSa9pa3X0/RQB4Brf7WP7LHhn/hRf/CR/tLfs/8Ah/8A4ag/sj/h mj+2/jJ8OtK/4aI/4SD/AIRb+wf+FF/b/Edv/wALb/tv/hOPBX9kf8IB/wAJB/aX/CYeFvsf nf8ACQaT9rP2adb/AOEg+HXiO/8A+FF/8M7/AGf9oD9rHRP+EA/sj+xP+Eg/4Rn9qf4yeHP+ F6fY/wDhFvB/nf8ADUH9lf8ADS/9r/2Td/8ACQf8Lb/t7/hKfHH9pf8ACa+IPf6KACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKAPzA/wCCwnwt8CfHH9iKX4KfFLQv+Eo+GXxg/a//AOCZ/wAL fiL4Z/tPWNE/4SLwJ8QP+Clf7JHhPxdoX9s+HdQ0jxBpH9r+H9X1DT/7T0LVdM1iw+0fatM1 CyvYoLmL8ofjn4m+Mv7Utl+zr4d/aMtvEGoav/wTC/bf/wCCaeg+L/G+q+E4PCcHx/8A22vE P/BYHwF+yVon7QV1ovhzRvCWnfBrxBcfsX+ANc/ac0/9na3u/HPgfU/g1/wVr+CnjaGzbSPh p8APi58SP6ffE3hPwr400620fxj4Z8P+LNIs/EHhPxZZ6X4m0bTte0618VeAvFWjeOvAvia2 sdUtrq2g8QeC/G3hzw94x8J6zFEuo+HPFWhaN4h0e5s9X0uxvIOfvfhP8LNR/wCEj/tD4afD +/8A+Ex+IHgr4seLvtvg3w5df8JV8U/hr/wgH/CuviX4j8/TX/tz4geAf+FUfC3/AIQrxlqf 2rxH4V/4Vr4A/sLUrD/hDvDv9nAH5Q/Cj9or9ofVvjL+z18T9e+M3iDXfBP7TP8AwUf/AOCg H7CGrfs6XvhD4SWnwa+GHw9/ZHg/4KJw/D74l/C/XNF+HOlftBn4weJpP2EPAV14+vPib8dv iZ8M7+f4pfGRfC/wv8I2118LLf4U+P8A/BILxh8dvh58LP8AglJ8HfHHxi/4Wj8P/wBo3/gk BYfHTT/B8vw98HeDPDnwM/4Zp8Of8E+/h78LfC3wputCtZviBqv/AAmHw/8A2oNVuv2gNb+M fxC+K3/CZ/FPwZovjD4LaR+zl8P9R1P4Ov8As9o37PXwC8OfGXxZ+0Z4e+B3wf0L9oPx74ft vCfjr47aN8NPBel/GXxp4Vs4PDNrZ+GfFnxPsdFg8beI/D9rbeC/B1vbaNrGuXmnQQeE/DMM Vsseg6WtrgfAv9k79lj9l/8A4Sn/AIZo/Zp/Z/8A2d/+E4/sT/hNf+FF/Bv4dfCT/hMP+EZ/ tf8A4Rv/AISn/hAPDnh//hIP+Ef/AOEg17+xP7W+1/2V/ber/YPs/wDaV55wB/PD4D/a8/aH s/hTP+1LYXviDx1+0j8fv+CUH/Bslo3ijXfBmg/CSx+IWveNP21P20P2wfhB8TfFnwr0Dx7L 4P8A2fNG+MBj+NXijxJ8Ibb4lWtl8AtB+JkfhR/iN4Z1H4XWWveGrz9nv+Ce/wARf2gPG3g7 48eGf2h4PiBF4g+D/wC0A/w68GSfHHxF+yBrf7TFz4E1P4E/Ar4txT/tJab+wt4u8Sfs5eEP iAvjP4o+NLbwP4d8LaN8P9Yuf2e7f4KeLPFfhG98QeKL7x742+n7b9nr4BWfhXWfAtn8Dvg/ a+CfEfwf8M/s9eIfB1t8NPBcHhXXfgF4L07xZo/g74Haz4ei0VdI1T4P+E9I8e+OtL8M/DS+ s5/Beg6d408WWOl6La23iPWIrzoPhb8J/hZ8DvAmhfC34KfDT4f/AAf+GXhf+0/+EZ+HXwt8 G+HPh/4E8O/23rGoeItZ/sLwj4T03SPD+kf2v4g1fVdd1P8As/T7f7frGp6hqd15t7e3M8oB /KF8dP8AjGb/AIJ4/wDBT34wQf8AEu+CX7aP/EQP8Avjhs/0Pw54K/an8K/ta/8ABRv/AIZY +NWsbP7A8JeHP+F7+Eo/EX7HfxP+I/i7U/FXxF+J/wAU9F/4Ji/s+fDrRrfTNOvsfo//AMFF P2sP2zPh58ffjv4O/Zs0n4wS6R+y1+xB8LP2sNNvPAGsf8E/vBvwC1T4hfEfxp+2DpZ0n/go B46/bh+IngXxt4f/AGYLK2/ZY8Ly3OsfsheIfhx8TPDHgvV/j7rHi34iWmry/Bu+8K/s9P8A Cf4WXPgTxd8Lbn4afD+4+GXxA/4WL/wnvw6n8G+HJfAnjb/hcGseIvEXxb/4S7wjJpreH/En /C0fEHi/xZrvxF/tnT73/hNtY8UeItT8Tf2ne63qU9zz/wAR/wBnr4BfGPxV8MfHXxd+B3wf +Knjb4J+IG8WfBnxj8R/hp4L8ceKvhH4qfUfD+sP4m+GPiHxPouqav4C8QNq/hPwrqjaz4Vv NJ1FtR8NeH743JudG06W2APxh8L+IPi7+zJ8aP8Agpt+0NZ/HX4geMvhl4K/4K//ALMs/wAf Ph9418NfBOx8Had+zj8T/wBgX9iH4efEfxde/ELwz8JPDniD4V/D/wDZZ8P/ALRXgD9oPx/8 RfEep69ar8Cf2BvDnh7xr4i8JXvxE/aK+Pni7x+b/gpT+3nY/Az4r+K/EPw18QfCb4rfsxfs wftm/wDBSL4k6J8YPhu8+nar8M9Q/Y98C/H/APZH/Y8+KPhCHwX8KvEngXw/4N+Mn7WXjH9n zT/jbo/iLwp8Qvjl4q/4I1ftIadLYWPin4g/HTw58Bv3+uv2evgFfaj8a9Yvvgd8H7zV/wBp Tw/pXhP9ovVLr4aeC7jUfj94V0LwrqHgXQ/DPxrvptFe5+Knh/RvBOrap4O0rRvHUuvadp3h XUtQ8PWdtDpF5cWcnoFt4T8K2firWfHVn4Z8P2vjbxH4f8M+E/EPjG20bToPFWu+FfBeo+LN Y8HeGdZ8QxWy6vqnh/wnq/j3x1qnhnRr68n07QdR8aeLL7S7a1ufEesS3gB+MPxz+OP7TH7K /wALP+Ct3w9s/wBpL4gfGjxb+yv/AMEwNE/bW+CPx0+MXgf9nuH4p+FPin8RvDn7fuiJoF1p Hwa+Cfwe+CXiP4f+CNT/AGRPAHjDwfpXiP4O6r4jm8R+K/iFa+NfFfjLwlfeEvC3g3x/4gfE n9of4A/8FAfiL8OtX8beINd1f44/swf8EsvhJ8cv279J8DfCTSfCv7NGo/G79sz/AIKneDfh 9H8O/wBnu+1zX/EmseIPiL8ZPib8Pf2Yv2T9N1rwr+0N4V+B+nato/x0/ba8e/HHSPhP41sv 2hv2f8AfsnfssfCj4WeNfgX8Lf2af2f/AIa/BL4lf8JH/wALF+DvgD4N/Drwd8LPH3/CY+HL Pwf4u/4TX4e+HfDmneEvFX/CVeEtO0/wt4j/ALd0i/8A7c8OWFnomp/atMtYLVO/8R/Cf4We Mf8AhP8A/hLvhp8P/FX/AAtf4f2fwn+KX/CR+DfDmuf8LK+Fmnf8Jr/Z/wANPH/9p6bdf8Jj 8P7D/hZXxF+x+DfEX9o+HLX/AIT7xr5Gmp/wlWu/bwD0CiiigAooooAKKKKACiiigD//2Q== --------------46B1D4483E2F15487BE06550 Content-Type: image/jpeg Content-ID: Content-Disposition: inline; filename="C:\TEMP\nsmailPK.jpeg" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAAR CAE9AqsDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD+/iiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK/IG8/4KF/FP 9r/4p+JPgt/wSZ0z9n/42eEvhr/whSfHr/goJ8UPFXiPxj+xt8LPEfiLxH4A1y7+DXwY0T4P z2ep/to/tAW/wS1rxP448UeEvBHxj+Dvws+D19f/AAz0r4l/G618W+LJvh9a9/8A8FCfEfx2 +Jvjv9mn9gL9nbx/8QPgX4g/a3/4XL41+Pf7S/w3s/Bx8d/Ar9jb9n3R/BVh8Z734Q694n8a 6Le+Df2gPir8Tfjb+z78EPhh4/0HwF8Vb74W6P8AEb4gfGGz8Oaf4g+HHhzVof0f8J+E/Cvg Lwr4Z8C+BfDPh/wX4J8F+H9G8J+DvB3hPRtO8OeFfCfhXw5p1to/h7wz4Z8PaPbWekaD4f0L SLOz0vRtG0uztdO0vTrW2sbG2gtoIolAPgDwn/wTwn17wr4Zl/at/bK/bf8A2mfjJp/h/RtK 8QfE/wAJ/tO/GX9hnwreT2mnWzata+GfgT+wB45/Zr+FOm+H7jxTN4i8Q6NqHj3R/in8ZbPT tftvB3in41+N/DfhHwZa6Dz/AMWf2A/+CYH7O/ws+Jfx0/4Z7+H/AOx54S+EXw/8ZfEv4o/G L9imz8f/ALGXxTtPhZ4B8Oal4w8babr/AMQv2GL/AOEnxt8cfD+30zRP+Ep1X4T/ANr+JPDn ibxH4Y8K63/whuseLfC3hG6039P6/MD/AIK8/wDBPbx3/wAFQ/2Nta/Y88I/tLf8Mw+H/HPx A8CeIvil4m/4U1o/xq/4TzwJ4DvrrxZp/wAOv7G1Pxr8P73wv5vxN0z4dePP+Eu8O+J7TWI/ +EC/4ReeC88P+KddtpADwD9grxN8U/if+yd8Kf2tP+Ccf7UfxA/ar/Zy+NH/AAnXjLwz+zp/ wU58Q+Iz478G/aviT4x0vWfhP4L/AG0PCfgbxz8evAX/AApXx1eeOPDPiPUv2hvB3/BRj/hY mj/CzwD8PPhL8S/h14Murn4za99v/sQ/tveFf2xfCvjjR9Y8D+IPgD+1H8AfEGnfD39rj9kf 4hajp198TP2d/iZfac2p6Zb3Gp6YsWkfEf4P/EfSIpfGPwB+P3g6KT4e/G74eyQ+IfD02na5 p3i7wj4U/nh/4M/P2O/in8E/2E0/an/4aQ/4S/4Jfto/8JX4j/4Zi1L4eeI7P/hTvxT+C3xi +IvwT/4T/wAG/EL/AIXHf+Err/hZXhLwds+Jdn/wo/SfEfiL+xfhPY/8Jrb6Z8Lvsniz9vv+ Cgn7JfjvxVrHw+/bl/Y88M/8bB/2XP7Di8EW2lfEPR/hDa/tXfs4/wDCd6J4m+OX7C3xp8Wa /wCDvHHhLW/h/wDFvwlb+J7r4OX3jvw/9l+CP7R0ngf4reF/Gfw2t/8AhO9Z1YA/T+ivAP2X P2kPAn7W/wACfA3x++HWj/EDwv4f8Z/8JNpmoeCfiz4I1j4b/FP4c+O/h/4x8Q/Db4pfC34l +BtdjW98N/ED4XfE3wh4u+HvjLT4LjU9HHiPw1qU3h3XfEHh+XTNc1D3+gAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD84P2DLnxV8XviF+21+1v4 /wBG8P6Vq/xD/af+Jn7Kfwit9G8Tajr2o6H+zB/wT4+JnxM/Zz8LeH/FkJ8J+C9DtfEHiP8A ajg/bI+P1sbay8XeINN8K/Hzwz4G1v4m+KdI8C+FdD8Hfo/XwB/wTg+KWj/E/wCC/wAao7LX fh/qfiD4b/t//wDBS34W+NdG8AaZ4E8P/wDCG6x4X/b6/aKufDeheNfDPgDT9IstI+IGr/DL V/AHj3xHqfiPTYvHfxE/4TOz+LfjXUPEviD4gXnizXvAPB//AAXR/wCCcfxX/bs+Dv8AwT0+ AXxl/wCGj/jb8Xv+Fhf8Vb8C7bS/G/wJ8A/8IB8Hbr43f8VT8Zf7c07wl4q/4Srwlp2s6Zon /ClZ/iz/AGH4x0PV/CvxH/4QPU7TY4B9/wD7SH7Qmj/s4eBNH8V3PgP4gfF7xb4x+IHgj4W/ DH4KfCFfAl18Xfiz478b6xHaroXw/wBK+I/jv4a+Er//AIQ7wla+LPi98SNT1nxnoej+APgn 8Nfif8VPE2oWHhLwH4g1C0/ODWfhD/wW8/aZ+DXhPXL/APbW/Zg/4Jl/ETxJ4gufHeo/DD4N /sZWn7X3xC+FvhW9n8TL4Y+Bvj747fGb9pJ/g38VPEGjeG9W8MTfFDxv8Nf2c/h7p138TPDd 7b/DnX7n4dh7rxd6/wDHj4W+BPiB/wAFcP8Agm94s8XaF/a/iD4Hfsgf8FPfil8LdQ/tPWLD /hF/Her+N/8AgnR8FNQ137LpmoWVlrf2j4ZfGD4i+Gf7M8RW2r6PF/wkX9swafF4g0jQtV0z 6A/aX/bM+FnwB/tb4aaF4i+H/wATf2x/EHw/v/FP7Pf7FNn8TfDnh/47ftB+I73+3tK8CaR4 c8KLF4g8W+H/AIf+IPFvh/U9N8a/HTUPBt78LPgt4O8P+P8A4s/FLW/D/wAN/hl481/QwD+U L/ggr+xp/wAFYfiv/wAEnv2U/H/7NH/BaD/hk34Ja/8A8Lz/AOEK/Z//AOHdP7Nvx3/4QH+y /wBpP4xaL4j/AOLreP8AxRp3i3xV/wAJV4t07XvGv/E2sof7D/4SP/hHLDzNM0eylc/4Nuv+ CbP/AAXm/Zf/AOEC8XfGr9ob/hl/9iV/7N17/hiP46aZN8c/GPjDw5qvleMfsHhb4Z/8JFo/ /DGX/CT/APC3fiP4i1vVtG+Ivg/4p6V8dvBmkQfH39mj4heGofsE39Pv/BLH9in/AId2/wDB Pv8AZe/Y6udf/wCEo8QfB/4fz/8ACea7Bqv9t6PffFP4geJ9f+KXxa/4RHU5PCngm9ufh/bf E3xt4ss/h1/bPhjTPEcPgS38O2/ib7b4gi1LULv7/oA/GH/gmL4s8K+Av2wv+Czf7EWh+Jvj B4rufgX+2/4W/apsbj4j6zp2u+FfCfhX/go98DPBH7RmqfDr4YzWdzZyaD4f0L9oOz/aL8St 4Rh8J6Rp2l6d418P6zceIvHPjbxJ461xf2er8wP2ZvEXjv4if8FP/wDgqP4s1D4df8Iv8Mvg /wDD/wD4J9/sdeEfHn/CXaPrf/Cz/Hfw/wDAHxz/AGw/iLef8IvBBY+IPBX/AAiXh/8Ab5+F vhn7Pqdtqej699n/ALZ0LxPe3sviLwx4N/T+gAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD8wPGsHgT4P/t2XvwU8f+Ef+Ew+Av8AwVp+H/j+DxH4 Z8R/DrWPGnwsuP2sf2efg74c8J+NfCPj/Wbzw74w8L33/DXf7DHh2y0+z+HXjXVfh98NtE8O f8E+fGt14c8O+PfHXx38f3Nl+QPh/wD4NR/2Nvg//wAFJ/gV+1z8EdL+H+r/ALIvh3/hJdN+ Mn7BX7QnhK++OPgS4/tf4C/FvwLZeMvAfjH4oal8QL3xR5XxN1P4TeL1+GnxV0jV/wCxNYi8 d+PfDnxYsIdI8A/Cmy/o+/aQ/Zo+Fn7U3gTR/BXxO0nde+CfiB4I+Mvwh8f6ZYeHLnx38D/j t8LdYj8R/Cv43fC288V6D4o8P6Z8QPh/4giW909PEHhzxJ4O8UaPc674A+I/hLxt8MvF/jPw V4h/KDxN/wAFtPCv7Kv7XFt/wTw/b1+FHiDwn+1h4v8AD/hPWP2XfFHwBj07xt8Gv26IPHut 6N8NfhPZfD2w8R+KdP8AEn7L3xg+M3xkt/iF4Mh+EH7Revt8Gvg9P4JuJ/Ff7aHi/wAHap4b +I3iMA+QPjD4T/4N4vAX/BST4HeBfEfhn/gjD4L8E+C/2YP2+vCfxy8Ha3o37D/hzwr4T+Pv hz48/wDBP7R/h94Z+LHh6+trPSNB+MGhaRZ/H/S/BujeL7O18aaXp1r8YbHRLaC2g8axL+z3 2H/gnH/wTQ/0LwB8Iv2f/wBmbxb8d/8AkE/Cn9lz9nTS4/jt+0T/AMKw/e3/APwg37P/AOzR 8O9X+Nvx+/4VHpnjy88R+Jv+EK8AeNf+FV+Dte8Q+NfEf/COeEjr2tRfzg+Lv+Dd/wCLv7UH /Bavw7/wUd8WaF/wwb8EvEfkftTto3wG+JPwT+Kfxs8H/tY/CvXvh1c/DF/GfhnxB8BbL4Jf DL4gfE3U722+NvxfsfDNp+3z8NtV+Lvws+O+maz8cPEemfGj4ceLIf6vvgX+y58Cf2cP+Epv fhP4G/s7xb4+/sT/AIWX8VvGHibxj8V/jt8Wf+EV/teLwb/wuL9oD4seIfG/xt+L3/CB6Zrm peHPh9/wsvx/4q/4QDwc9r4K8G/2H4S07TdFtAD5fuf2rf22viL4q0bTv2cv+CcPiC3+Hd94 f8TeJpPjR+29+0b4H/ZL8K6/p0Oo+E4Ph3beB/hd8KPBf7Y/7UemeIPiBoeteIPFeo+E/wBo z9nz9mvxV8M9O8Mr4d+IGjaP8RNSuPBOj+f/ABr/AOCl3ir9hrwrp/j/AP4KRfsweIPgX8G7 nxBa6V4h/al/Zi8caj+2X+zB8KINd07VU8HWvxouovhj8C/2sfBviDxR4x0VfA0GoaD+x941 +DVj4g8efB/Srn41nxJ451jw34L+/wD4/fH74NfstfBr4hftB/tB/ELw/wDCv4N/Cvw/N4m8 deOvE006adpGnJPb2NnbW1nY295q+u+INd1e807w74T8J+HtO1bxV4y8Vato3hTwpo2s+JNZ 0vS7v8wfgXc+Kv8Agr7p37Pf7X/j7RvjB8A/2D/D3iD4L/tN/sofs7al4m1H4afGX9oP4mfD zxV431rRvil+3J4N03wndW0Hwf8ABfjfw58G/jf+xr8M/g98e/FPw9+J8Gn6V8dPjneeObDX vhx8L/hcAev/APBJnwB9m/Zx8b/tRz+NfiB41vf+Ckf7QHxL/wCCilj/AMLF8R/8JHrHgn4W ftG2vhj/AIZf+FcG+yWbw3/wq79kXwh8AfA3iLwPD4h8deHPBPjvQ/F3hn4e+N9c+GWmeC/s 36f1/ND+yt+1b8Pf2CP2oPiL+zb8HvgJ8YPFn/BPz9sjxB4u/am/4J0XHwb0n4ZzeFdG07wF 4f8ADsn/AAUMsf2aPhR4z/ayf4yfFT9mDRvEmreE/wBqr9nr4c/sofsxp4q+MOnfFX9onxn+ yH8EPjb8A9L+GHxE8Yf0feE/FnhXx74V8M+OvAvibw/408E+NPD+jeLPB3jHwnrOneI/Cviz wr4j0621jw94m8M+IdHubzSNe8P67pF5Z6po2s6XeXWnapp11bX1jcz208UrAHQUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFc/4s8WeFfAXhXxN468deJvD/gv wT4L8P6z4s8Y+MfFms6d4c8K+E/CvhzTrnWPEPibxN4h1i5s9I0Hw/oWkWd5qms6zql5a6dp enWtzfX1zBbQSyr/ADRf8FOP+C9njH4EfEX4AeFv+Cddj+z/APtNeEviH+z/AP8ABR34xeNf ih8RPD/x2HwJ1/8A4Y4/ZYuPj34cuv2dP2mvAFlH8Evjv/wjmp6B430j4u+D/hXrfxH8vxj4 bsvgX44+IX7NHi3W73x54cAP6fa+IPFn7d/w9fxV4m+H37Ofw0+MH7b3xE8BeINZ8MfE7w5+ ytZ/DPVPCvwr8QeFtRudE8aeD/iL8f8A41fFD4J/sueGvjB4H1w6HY+Lv2bLj45SftQaNp3i zw741m+CzfDuTVfF+k/zQ+N/2+v2jvjn8E/2Y/iv8aT/AMNBaZ+1Z+0B/wAE1/2Uo/2ZZ/iP dfsxfsWJ+1j+2/8ACL9mf9q/Uvhf4u+Fvwk+GnjP9pL4hfsgP+wn8c/E/gX4i+MP2k/2zf2r /ht8Qv2nde8RQ+MP+CYfiz4JWXgK38GfYH7VP/BbbWP2HNY/4JS/Dv4Y/sw/D/SPhL+0R8QP 25/2NPH3wN8EeG/Hfia6+Hfxs/Yk8d+Hf2QPhf8AD79m+/8Ag34a/tr/AIZ//wCGmt2jx634 f/ZP+IPxd179nG00fVvhx+y1pvxaey+C1yAfr9/woL9qf9oj/Sv2sfjV/wAKU+H83/NsP7DH xH+Ivg/7X5f7v/i6P7dv9jfCT9prxx9n1rRPDnxC8E/8M0+D/wBg/wD4Rn+1fF3wd+Mn/DUH w/uv7U1L2DRv2Iv2L/Dnwa8Wfs5+Hv2RP2YNC/Z88e+ILbxZ46+BOjfAL4U6X8GvGniqzn8M 3Vn4m8WfDCx8JweCfEfiC1ufBfg64ttZ1jQ7zUYJ/CfhmaK5WTQdLa18f/aP/bC8d/DX9iz4 XftWfDb4HfECbxb8SviB+wTplt+zx8UvDWj+DvjZYaP+1l+07+zz8I/Fnwt13wv4m+I/gPwl 4I/aA0Pwl8Xtc8P6Zp/jb4m6P4E8HfF2w08eOdduvCWl6yLr4A/Zw/4LYeI/iBo/xR8V/Gv9 mv8A4Vz4M+F37X/7e37F/iaef4r/AAs8IfEnwv8AHb9kjwJ+0N+1ro3gjxd4a8WeO739mvRP h/b/ALFfwf0rSviL+0rqH7a2n+Dov2sW8RaBa/Dvw3+zkbb486YAfQHj/wD4Iufs/wCr/Czw V8JPgX+1N/wU/wD2N/D/AMP/APhHNM8LXP7NH/BS79r+L+yPAnhTw5e+GdE+Fuk+E/jp8T/j j8MvDvw/sLKXSJLDT/C3gLQtY0j/AIRfQdN0TXdM8PjV9G1fv/H/APwTf+Ivxb/4QrT/AIpf 8FUP+Cn/AIg8JeD/AIgeHPH954R8AfEf9lj9l/8A4Tj/AIR/7bBceCvGvxF/Y6/ZE/Z3+Nt3 8P8AxNpmpahpniPw5oXxS8P/AGjzrPXdMvdK8W+H/DHiLRPmDw7/AMFNf2uPE3ir9i7x7rXw O/Zg+FH7PnxB/Yg/bn/bL/bB8Gan8ftb8V/H34X6j+yJqPgLwPrv7Ovh7xb8T/Cf7K/wJ+Ef xg+FXxJ+L/wv8L/tBn9onXtA8K+B/Gmn/tDfDLxlrfwmk+Ael/EP4w+/6x/wUA+Mp/4JwfBr 9tSw+AXh+x+MnxF+MH7JHgDxR+y94Z8fwfEzxB4P1H43/tv/AAi/Zi+JvwIufFXj22/Zc0jQ /wBp/wCH2keN/E/gHxZ4W+JX/CvfCvwV/ag0DWfAPxG1TWPDfgTXtW1kA+oPhb+wj+zP8JvH ehfFLTfC/wAQPiR8TfB/9p/8K6+Iv7Svx/8A2hP2u/Hfwi/4SDR9Q8O+Lv8AhSPi79qn4p/G TxB8EP8AhPvD+pSaF8Sf+FSah4M/4WVo9joOmePf+EisvDXh2DS/n/8A4LM+P/8AhWH/AATY /aQ8a6r4K+IHxI+GWmf8Kfs/2kvAHwt8Of8ACUeO/GX7G3iD49fC7w5+214c0KzW90ibSP7X /ZF1f412Wp+NbXxH4Mvvh3o8uoeP9P8AH/w/vfDVv410H4A+IP8AwXe8d/Bb9l39oj9pD4hf slf2j/wyp/wuHxF8efAV58UNH+Hfjvwho/ir/gol+2V+wD+xZ8OvDGl+F7X9on4f/ET4gX/x A/ZUm0/9sXxdb/GDwr4E+F2j39x8UfgDB+0T/aNp8ItJ5/8Aaw/4KXeKvjx/wTH/AOCsPw5+ I37MHiDw38dvDfwf+JP7L/hr4Y/s4+ONR/adg+Ivir9p39qT9q3/AIJN/CB/CGp678Mf2ffG Op+INT/ax/Z9+JV/q/guw+Gt/qMXwav/AIa+J/DF94u+JPi7X/g/4GAP2f8AjV4A/wCGkdH/ AGQ/jp8BPGvw/wDFF78H/wBoD4UftL/CvxTN4j/tv4RfEL4WfEDwJ42+Bfxe1a01vwZZa7N4 s/tn9kX9or4z+KfgLf8AhzV9M8Oaj8bLf4P634n169+GUXivSNb+QP8Agl98RfAmp/FP9vrw L8NoPiBB8MvHn7QEn7dPwLj8UeItY8U+Dpfgn+1V4j+JXwk1fxn8L9S1vxd4qhg+H/7Rf7XX 7Hv7X37Zvwzi8BTP8IvFHwJ/ae+DHxX8C31pe/EzxT4C+H/w/wDtl+L/ANm4/s1fs6/tefs7 /s1ftP8Ax01f9u3w+f2oLT9ibwh8bP26dY8F+OPhJ4o+CGt/tNfEhPiV/wAE7P2VPi74u+BP iLw/+0f8Sdb+F/7Lf7R3jTV/hF4y/Z48NfH39t3SPjz+1LY/HnSNa8WfD742eQftW/8ABazw J+x1/wAFP7fxZ8P/AIRf8NMfDL9tb4f/ALO/7DPw/wDHnw98faxq2fjZ8CvAF/8Ath/Dfxl4 P8L/AAh+FXx38QfGT9n/AONfh/8A4K+/sw+GbXxj8K7bxH8XdL/4Rb4xaz8O/gH8ab3S/hh4 Y+LAB/V7RX5gfEL/AIKTf8It8Xf+CePwL0b9nn4gWHxN/wCCl37P/wC0v8UPgp4W+Nmp/wDC mtY+FPxT+AnwT+G3x00r4MftO6Ja+HfiJ4g+GH9veH/GXibwt8QvFHhPSPid4j+FPjvwjaaJ bfDP4hWWvahq/hb6A/4J+fHT4p/tPfsO/smftIfGvwt8P/BnxN+Pf7P/AMLvjF4m8O/C3W/E eveBLT/hZHhLTPF2jXWhT+LNI0jxBpH9r+H9X0rWNT8H6hJ4l/4QPWL/AFDwRa/EL4nWXh+2 +IvikA+v6KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACivAPjp+1V+zj+zR/wi1t8dfjR8 P/hv4g+IH9twfC3wFrev2svxT+M2seH/AOyI9Q8I/Av4SaYb/wCJvxx+IEt74i8NaNpHw6+E nhPxn478Q+I/FHhbwz4f8O6n4g8S6FpuofP/APwn/wC2T+0z+4+D/gr/AIYu+CWo/J/wvD4+ +HLHxV+1P418OXnyf2x8Ff2WPtsnhL4Ef8JH4S17TPF3w4+J/wC2J4i1r4p/DD4i+FdZ+HX7 Qf8AwTF1HTLj7cQD6/8Ail8WPhZ8DvAmu/FL41/Ev4f/AAf+GXhf+zP+Em+IvxS8ZeHPh/4E 8O/23rGn+HdG/t3xd4s1LSPD+kf2v4g1fStC0z+0NQt/t+sanp+mWvm3t7bQS/IH/DT/AO0d 8b/+JV+yr+yh8QPCnh/WONM/ac/bW0a6/Z/+Fmm6Of8AiR67r+gfsw6hqVt+3P42+IHgnxRc m60r4L/Gj4Kfsb+BPjJ4c8JeK9Q0D9qrwL4f134W+NPH3oHwt/Yp+Fngbx3oXxp+I2v/ABA/ ai/aN8Nf2n/wjP7Q/wC0rqvhzxn478Bf2zo+oeFNZ/4Uj4L8J+FPAfwF/Zh/4SnwLd2Pgf4k /wDDLPwc+Cn/AAurR/D+g6r8b/8AhZHjO1ufFN59f0AfEHhP9iHwrrPirwz8V/2rfHHiD9sP 4yeFfEGjeN/B118UdO07S/gF8FfHGh6jbeJPD2u/s3/staO0vwp+HHiD4ceKZfEcnwf+O/j2 3+Mn7bXg/wAF+J9Q+Hfin9rv4h+G44kP0/4u+E/ws+IGseHfEXj34afD/wAbeIPCHkf8Inrv i7wb4c8Sax4X+zeO/h18Urb/AIR3U9Z029vdE+z/ABN+D/wk+IsH9mz23leO/hd8OvF0e3xB 4J8M6hpnoFFAHzB4m/Yi/Yv8aadbaP4x/ZE/Zg8WaRZ/B/wn+z1Z6X4m+AXwp17TrX4BeAvF WjeOvAvwOtrHVPCd1bQfB/wX428OeHvGPhP4aRRL4L8OeKtC0bxDo+i2er6XY3kHQeIv2Tv2 WPF+j/Drw74s/Zp/Z/8AFHh/4P8Aw/8AF3wn+EmheIvg38Otb0f4XfCz4geBIPhb49+Gnw60 zUvDlzZeCfh/42+GVtbfDrxd4N8MwaZ4c8SeBLeDwjrOm3vh+KPT19/ooA8/g+E/wstvAnhH 4W23w0+H9v8ADL4f/wDCuv8AhAvh1B4N8OReBPBP/Cn9Y8O+IvhJ/wAIj4Rj01fD/hv/AIVd 4g8IeE9d+HX9jafZf8ITrHhfw7qfhn+zL3RNNntuAn/ZO/ZYudY8XeIrn9mn9n+48QfED4f/ ABF+E/j3XZ/g38OpdY8bfCz4weO/EXxS+Lfw08XanJ4ca98SfD/4o/E3xf4s+IvxF8G6zPe+ HPG3jvxR4i8XeJtN1PxBrepahc+/0UAeAeIv2Tv2WPF+j/Drw74s/Zp/Z/8AFHh/4P8Aw/8A F3wn+EmheIvg38Otb0f4XfCz4geBIPhb49+Gnw60zUvDlzZeCfh/42+GVtbfDrxd4N8MwaZ4 c8SeBLeDwjrOm3vh+KPT17+D4T/Cy28CeEfhbbfDT4f2/wAMvh//AMK6/wCEC+HUHg3w5F4E 8E/8Kf1jw74i+En/AAiPhGPTV8P+G/8AhV3iDwh4T134df2Np9l/whOseF/Dup+Gf7MvdE02 e29AooA8A8U/snfsseOP7I/4TX9mn9n/AMYf8I//AML0/sH/AISn4N/DrxB/Yn/DUH9t/wDD S/8AZH9reHLv+zf+GiP+Em8R/wDC9Psfk/8AC2/+Eg1v/hP/APhIP7Vv/tG+v7PXwCTTviPo 6fA74PrpHxj8P+IPCfxd0tfhp4LXTvip4V8WeKvid468VeGfiPYjRRbeOPD/AIl8bfGz4zeM fEGjeJ4tU07WfFXxc+J3iHUba51fx74qvNW9gooA/OD/AIJdeE/Ctr+xL+yLo+qeGfD998Vv 2Qfg/wCLf+CfuuePW0bTrnUYPFX7Jfjiy/ZS/aLg+HHim4tl8SRfB/4nfGT9lCx8Y+H47yLw zqPjTwr4b+GPiHx14M8N+KdHh8OeHPkD9p//AIJ7/s1aF/wUH/4Ju/HLxB4K8P8AxD0jxR4g +LX/AAT38BfADxT8NfghovwC+Bf7NWvf8E5f2tfF+veCvAHhz4ZfCr4e+NvHfh++tvghqPgr S/hr+0p8Qfj58EPA3gv46fHex+G/wq8G6v4p8L634K+3/wBgX/ikv+G1PgF/yEP+Gfv2/wD9 o7/irP8Aj0/4S3/hsD/hDf8Agpd/yAv9J/sH/hXf/Dcf/Clf+QzrX/CW/wDCr/8AhY//ABTP /Ca/8IH4SP8Agon/AMU/8Ov2cvixpH+ifED4Sft//sD/APCvdf8A+Pj/AIR//hoj9qf4afsU /GL/AIlV152i6r/wmH7Mv7UHx0+Gn/E703Uv+Ef/AOE4/wCEy8Lf2J8QPDPg/wAV+HwD6ftf 2evgFY6j8FNYsfgd8H7PV/2a/D+q+E/2dNUtfhp4Lt9R+APhXXfCun+Bdc8M/BS+h0VLn4V+ H9Z8E6Tpfg7VdG8Cy6Dp2o+FdN0/w9eW02kWdvZx9B8LfhP8LPgd4E0L4W/BT4afD/4P/DLw v/af/CM/Dr4W+DfDnw/8CeHf7b1jUPEWs/2F4R8J6bpHh/SP7X8Qavquu6n/AGfp9v8Ab9Y1 PUNTuvNvb25nl9AooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAor4g8Wft9/BqDxV4m+G/wAD/C/x g/bC+K3hPxBrPgzXvBP7K3w+n8e+FfDnxC8J6jc2nj34V/EX9pzxRqPgT9i/4IfGD4e6dY3v iDxd8Ifj5+0p8LPiZa6c3h3TtO8Kap4p+IXwy8O+NOf/AOFBftT/ALRH+lftY/Gr/hSnw/m/ 5th/YY+I/wARfB/2vy/3f/F0f27f7G+En7TXjj7PrWieHPiF4J/4Zp8H/sH/APCM/wBq+Lvg 78ZP+GoPh/df2pqQB7B8a/2vPg18E/FWn/Cy6vfEHxP/AGg/EPh+18T+Dv2Y/gpoM/xL+Pvi Xw/q2o6r4d8PeMNQ8E6PKlt8K/g/rPjbSW+H11+0n8dta+FP7L/gfxpqGlaT8T/jT4Gjv4rs eP8A9n/8FBP2gP8ARtd1P4f/APBP74ZXf/Ewguvhprvhj9p79snWNH1L/ia+HdM1LUPiL8LW /ZF/Zk+IHhGbTtM0b4saFp/hP/go14E8d2Pinxl4Z+FvxS8B3vhDwj8a/Fv0/wDBT4A/Br9n TwrqHg74K/D3w/4C0jXvEF14z8Y3mmwz3nir4k/ELVNO0rS/EPxU+LfjrWLjUvG3xe+MHjG2 0PSpfHvxe+J3iHxZ8TPH+o2ceseNPFeu6u0t9J7BQB4B8C/2XPgT+zh/wlN78J/A39neLfH3 9if8LL+K3jDxN4x+K/x2+LP/AAiv9rxeDf8AhcX7QHxY8Q+N/jb8Xv8AhA9M1zUvDnw+/wCF l+P/ABV/wgHg57XwV4N/sPwlp2m6Lae/0UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfAHw I/4on/goJ/wUC+Fulf6R4f8AiB8P/wBin9tbWbzUP3usW3xT+MHhj42/sdeJtA0y4tvsllD8 P7H4Zf8ABO34Ka7oWlXWn3viO28d+KPilqeoeK9T8P634T8MeCT/AIKt/wCjf8Eyv2/vEVt/ o/iD4f8A7IH7QfxY8B67B+61jwT8U/g/8MPEvxS+EnxL8I6nHtvfDfxA+F3xN8IeE/iL8OvG WjT2XiPwT478L+HfF3hnUtM8QaJpuoWx4j/4pL/gqb8G/wDhHv8AiX/8NAfsAftLf8Ld/wCX v/hLf+GP/wBor9k7/hnT/j++0/2D/wAK7/4bj/aj/wCRZ/sX/hLf+Fof8Vz/AMJN/wAIV8O/ +ES+/wCgAor4A/4JSf6N/wAEyv2AfDtz/o/iD4f/ALIH7Pnwn8eaFP8AutY8E/FP4P8Aww8N /C34t/DTxdpkm298N/ED4XfE3wh4s+HXxF8G6zBZeI/BPjvwv4i8I+JtN0zxBompafbff9AB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFef/ABS+LHws+B3gTXfil8a/iX8P/g/8MvC/9mf8JN8Rfil4y8OfD/wJ4d/t vWNP8O6N/bvi7xZqWkeH9I/tfxBq+laFpn9oahb/AG/WNT0/TLXzb29toJQD0CivgD/hp/8A aO+N/wDxKv2Vf2UPiB4U8P6xxpn7Tn7a2jXX7P8A8LNN0c/8SPXdf0D9mHUNStv25/G3xA8E +KLk3WlfBf40fBT9jfwJ8ZPDnhLxXqGgftVeBfD+u/C3xp4+P+Henws+K/8AxPf259T/AOG9 /Ft1/pf/AAjHx98K+HL/APZY8A30/wDpn2f4K/sdeRqPwS8K/wDCK6nqPi7T/hx8Xvijpnxu /bJ0P4deMdZ+Fvjb9rL4leEn+zuAH/Dc/wDwuj/iW/sC/C7/AIbG83/mvP8Awm3/AAqf9hPS tn7/AP5O1/4RH4jf8Lo+3f2V4y8G/wDGFfwm/a4/4Vz8YvDH/CtP2jv+FCf2l/wktif8Md/F P40/u/25/wBpD/he/hKH/RP+Ge/gF8PPEf7Jv7LHi+xj+X7R8avAn/C4/jf8bfjz/b+mar4u 8EfEf4Q/FH9pDXv2Nvij8OtY0bR/G37JuqeLfDn/AAnmrff9FAHP+E/CfhXwF4V8M+BfAvhn w/4L8E+C/D+jeE/B3g7wno2neHPCvhPwr4c0620fw94Z8M+HtHtrPSNB8P6FpFnZ6Xo2jaXZ 2unaXp1rbWNjbQW0EUS9BRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHwB+1 x/xKP2ov+CWHiLSv+JZ4g1v9r/4x/CfWdd0//QtY1f4WeKP+Cdv7bXxS8TfDTU9TtvKvb/4f +Ivib8Dvgp8Rdd8G3U8vhzV/Hfwf+Fvi7UNNuPEHw/8ACeoaR9/18Af8FM/9G/Zd0fxFc/6P 4f8Ah/8Atf8A/BOL4sePNdn/AHWj+CfhZ8H/APgol+yz8Uvi38S/F2pybbLw38P/AIXfDLwh 4s+IvxF8ZazPZeHPBPgTwv4i8XeJtS0zw/ompahbff8AQB8Af8E7P+Kf+HX7Rvwn1f8A0T4g fCT9v/8Ab4/4WFoH/Hx/wj//AA0R+1P8S/21vg7/AMTW187RdV/4TD9mX9qD4F/Ev/iSalqX /CP/APCcf8Ib4p/sT4geGfGHhTw/9/18Afsz/wDFE/tp/wDBSj4W6r/pHiD4gfED9mL9tbRr zT/3uj23ws+MH7MXgj9jrwzoGp3Fz9kvYfiBY/E3/gnb8a9d13SrXT73w5beBPFHwt1PT/Fe p+INb8WeGPBP3/QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUV8wfGv9rz4NfBPxVp/wsur3xB8T/2g/EPh+18T+Dv2Y/gpoM/xL+Pv iXw/q2o6r4d8PeMNQ8E6PKlt8K/g/rPjbSW+H11+0n8dta+FP7L/AIH8aahpWk/E/wCNPgaO /iuwAfT9eAfHT9qr9nH9mj/hFrb46/Gj4f8Aw38QfED+24Phb4C1vX7WX4p/GbWPD/8AZEeo eEfgX8JNMN/8Tfjj8QJb3xF4a0bSPh18JPCfjPx34h8R+KPC3hnw/wCHdT8QeJdC03UPn/8A s/8A4KCftAf6Nrup/D//AIJ/fDK7/wCJhBdfDTXfDH7T37ZOsaPqX/E18O6ZqWofEX4Wt+yL +zJ8QPCM2naZo3xY0LT/AAn/AMFGvAnjux8U+MvDPwt+KXgO98IeEfjX4t+gPgX+y58Cf2cP +EpvfhP4G/s7xb4+/sT/AIWX8VvGHibxj8V/jt8Wf+EV/teLwb/wuL9oD4seIfG/xt+L3/CB 6ZrmpeHPh9/wsvx/4q/4QDwc9r4K8G/2H4S07TdFtAD5/wD+E/8A2yf2mf3Hwf8ABX/DF3wS 1H5P+F4fH3w5Y+Kv2p/Gvhy8+T+2Pgr+yx9tk8JfAj/hI/CWvaZ4u+HHxP8A2xPEWtfFP4Yf EXwrrPw6/aD/AOCYuo6Zcfbj6B8Lf2KfhZ4G8d6F8afiNr/xA/ai/aN8Nf2n/wAIz+0P+0rq vhzxn478Bf2zo+oeFNZ/4Uj4L8J+FPAfwF/Zh/4SnwLd2Pgf4k/8Ms/Bz4Kf8Lq0fw/oOq/G /wD4WR4ztbnxTefX9FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAfIH/BQn4W+O/jj+wL+3D8FPhboX/CUfE34wfsgftLfC34deGf7T0fRP+Ei8d/ED4L+ NfCfhHQv7Z8RahpHh/SP7X8Qavp+n/2nruq6Zo9h9o+1anqFlZRT3MXv/wAJ/il4E+OPws+G nxr+Fuu/8JR8MvjB8P8Awb8Uvh14m/szWNE/4SLwJ8QPDmm+LPCOu/2N4i0/SPEGkf2v4f1f T9Q/szXdK0zWLD7R9l1PT7K9intovQK+AP8Aglx/xJv2E/gZ8Jv+Pn/hlf8A4Wb+wx/b/wDq f+E7/wCGBPjF8Qf2Kf8AhaP9lfvf+EY/4Wx/woT/AIWX/wAIT/aXiH/hBP8AhK/+EN/4S7xl /YX/AAlesAB/yT//AIKm/wDQW/4a2/YA/wCvD/hX/wDw7v8A2iv+33/hK/8Ahb//AA9B/wCp b/4V/wD8KO/5nb/hZf8Axb/7/r4A/aY/4on9tP8A4Jr/ABS0r/SPEHxA+IH7Tv7FOs2eofvd HtvhZ8YP2YvG/wC2L4m1/TLe2+yXsPxAsfib/wAE7fgpoWhardahe+HLbwJ4o+KWmah4U1Px BrfhPxP4J+/6ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAoor4A/wCG5/8AhdH/ABLf2Bfhd/w2N5v/ADXn/hNv+FT/ALCelbP3/wDydr/wiPxG/wCF 0fbv7K8ZeDf+MK/hN+1x/wAK5+MXhj/hWn7R3/ChP7S/4SWxAPv+viDxZ/wUC+AUXirxN8Lv gRP4g/bP+O3g7xBrPhPxj8DP2RJPBfxQ8VfDjxV4a1G5sfEPhn47/EHWPGfg39nz9lrxBaR6 R4vn0LRv2qvjR8EdR+I+o+AfG/gn4UW3jz4k6DL4Kl5//hk34p/tBf8AEz/bn+L3/CY+Er/9 /wD8MdfAK48R/DX9lizsbr/SP+EV+NXif7XZ/G39tH7PpmteLvhb8R9M+KOu/DX9jb9oz4dX Wjah42/4J6eDvFth9sX7f8J+E/CvgLwr4Z8C+BfDPh/wX4J8F+H9G8J+DvB3hPRtO8OeFfCf hXw5p1to/h7wz4Z8PaPbWekaD4f0LSLOz0vRtG0uztdO0vTrW2sbG2gtoIolAPiD/hR37ZPx 5/4mH7RH7Rv/AAzV4Suv9Duv2dP2GNSsb/8AtXw5e/8AEr8YeHPij+2h8YvhRp3xt8Vf8JVp mnW+p+CfGv7KXwt/4J/fFP4If8Jj4u0Kw8f/ABK8W+H/AIffGbQPp/4KfAH4Nfs6eFdQ8HfB X4e+H/AWka94guvGfjG802Ge88VfEn4happ2laX4h+Knxb8daxcal42+L3xg8Y22h6VL49+L 3xO8Q+LPiZ4/1Gzj1jxp4r13V2lvpPYKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAr4A/YR/4pXxH+3x8C9P/AH3hL4Eft/8AxZ/4RHUb 3954j1H/AIay+FnwP/4KL/EX/hJLuD7Ppl5/Yvxt/bR+KXhbwV/ZmkaP/Z3ws0HwBomu/wDC R+LdL8ReOPFX3/XwB8GP+KV/4KO/t3+ANB/0Dwl4x/Z//YN/aj8SaT/x9f2j8dviVqn7X37N HjXxz9vvftGp2f8AbXwS/Yu/Zo8Ff8IzYXtr4O07/hWv/CR6T4esPFvjHx/r3ioAP+Cif/FP /Dr9nL4saR/onxA+En7f/wCwP/wr3X/+Pj/hH/8Ahoj9qf4afsU/GL/iVXXnaLqv/CYfsy/t QfHT4af8TvTdS/4R/wD4Tj/hMvC39ifEDwz4P8V+H/v+vgD/AIKt/wCjf8Eyv2/vEVt/o/iD 4f8A7IH7QfxY8B67B+61jwT8U/g/8MPEvxS+EnxL8I6nHtvfDfxA+F3xN8IeE/iL8OvGWjT2 XiPwT478L+HfF3hnUtM8QaJpuoW33/QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA V8gftK/HT4p+EPHfwR/Z7/Z28LfD/wAU/Hr4+f8ACydeXU/ilrfiPSPAnwR+BPwp0fQdP+J3 7Smu6F4f0g3vxo/4V18Tfin+z74D0z9nPQfHfwp8Y/FvWPi/p7WfxP8Ahp4F8LfEf4peAfr+ vgD4jf8AKU39jf8A7MA/4KWf+tFf8EnaAD/hXP8AwVN/6PI/YA/8Vp/tFf8A02Kj/hXP/BU3 /o8j9gD/AMVp/tFf/TYq+/6KAPgD/hXP/BU3/o8j9gD/AMVp/tFf/TYq5/Uviz+2h+zF4q+E l9+1F4j/AGYPjt8Cfix8YPAXwU8W/Fb4KfCr4rfsv+Kv2c/FXxW1GT4efA/UNQ+FfjD43fti yftEeH/jd+0H4r+E/wADLq68N+NfgtqPwM1HxnpXxB8R6V8RfhtdeO/Enwd/R+vzA/4LCeI/ +EO/Yil8Xf8ACf8Aw/8AhR/wiv7X/wDwTP8AEf8AwtL4s2f9o/Cz4a/2H/wUr/ZI1P8A4T/4 l6f/AMJr8Nft/wAP/B32X/hIvGVn/wALF8A/avDmnalB/wAJr4V3/wBu2AB9/wDxS+LHws+B 3gTXfil8a/iX8P8A4P8Awy8L/wBmf8JN8Rfil4y8OfD/AMCeHf7b1jT/AA7o39u+LvFmpaR4 f0j+1/EGr6VoWmf2hqFv9v1jU9P0y1829vbaCX5A/wCGq/jZ8ef+JH+x1+zn8QLCyn/0HXf2 if21vhj8Xf2VfhZ8PLqX/Q9Ti0D9n34peE/An7XX7QHxA8JQ6x4Y8c6V4Ms/ht8Dv2cfit4c TxX4Jt/26fhn8TfDuoaDZ/mB/wAE2P29f+CVH7bP7cTfDv4AfFb9oD/goH+1b8Mv2f8AxR+0 Jbftq/tK+BZLLR/hpo6+LdF+BnizwH8EfBvibwd8DPCX7NXxA1/wl8QvBWj/ABJX9k79k/4O eBPjh4EstB1b4z+O/ib8U9I1m5P9H1AHwB/w778CfFH/AInP7anxB+IH7afiDU/3niL4f/Ev XNY8L/sbNay/8TWDwRpv7CnhHW7b9nLxv8P/AAT4zudR8WfCfWP2o/DP7Tv7R3hC+i8G3Pib 9pD4geIPhh8OvEnhv7/oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAK+APGv/En/wCCpv7NP9kf8Sr/AIWN+wB+3D/wsH+z f9B/4Tv/AIUv+0V/wT2/4U7/AMJl9l8r/hJ/+FT/APC+/jp/wrT+2/t3/CCf8Lo+LP8Awi39 lf8ACxvGH9sff9fAH7av/Eu+NH/BMHxhqH+geEvB37f+pf8ACXeKb3/RfDnhX/hZX7Av7dvw L+HX/CSa3Ps0zQ/+E++NvxX+Fvwd8Ff2ndWv/CVfFP4leAPh7oX2/wAW+MfDukaiAff9fAH/ AASk/wBG/wCCZX7APh25/wBH8QfD/wDZA/Z8+E/jzQp/3WseCfin8H/hh4b+Fvxb+Gni7TJN t74b+IHwu+JvhDxZ8OviL4N1mCy8R+CfHfhfxF4R8TabpniDRNS0+2+/6+AP+Cdn/FP/AA6/ aN+E+r/6J8QPhJ+3/wDt8f8ACwtA/wCPj/hH/wDhoj9qf4l/trfB3/ia2vnaLqv/AAmH7Mv7 UHwL+Jf/ABJNS1L/AIR//hOP+EN8U/2J8QPDPjDwp4fAPv8AooooAKKKKACiiigAooooAKKK KACiiigAooooA+IJ/wBl/wCAXx/1v9qHwp+0Y/wf/bY8E6h+0/4R+I+l/A/41+C/Bfxm8K/s meKtJ/ZH/Z+8CWPwx0/wl46vvHukeE/EGqaQuuftB2rW/h3wFqK6d+1Dquow+H7i28WXnjDx t7/rP7PXwC8R/GXwn+0Z4h+B3wf139oPwF4fufCfgX47az8NPBeqfGXwX4VvIPE1reeGfCfx PvtFn8beHPD91beNPGNvc6No+uWenTweLPE0Mts0evaot1wHwC1n4Nap8Vv23bH4YeE/EHhz xt4c/af8J6N+0ZrGs3M8+nePfjLP+xf+yJ4h0PxZ4Tim8Ta7HZ+H7P8AZ8174E+Bbm2tdL8F wN4q8F+JrxvDN1c3Vx4x8WfT9AHgGifsnfsseGf+F6f8I5+zT+z/AOH/APhqD+1/+Gl/7E+D fw60r/hoj/hIP+Ep/t7/AIXp9g8OW/8Awtv+2/8AhOPGv9r/APCf/wDCQf2l/wAJh4p+2ed/ wkGrfa+f1n9iL9i/xH8GvCf7OfiH9kT9mDXf2fPAXiC58WeBfgTrPwC+FOqfBrwX4qvJ/E11 eeJvCfwwvvCc/gnw54gurnxp4xuLnWdH0Oz1GefxZ4mmluWk17VGuvp+igDx/Wf2evgF4j+M vhP9ozxD8Dvg/rv7QfgLw/c+E/Avx21n4aeC9U+MvgvwreQeJrW88M+E/iffaLP428OeH7q2 8aeMbe50bR9cs9Ong8WeJoZbZo9e1RbrA0T9k79ljwz/AML0/wCEc/Zp/Z/8P/8ADUH9r/8A DS/9ifBv4daV/wANEf8ACQf8JT/b3/C9PsHhy3/4W3/bf/CceNf7X/4T/wD4SD+0v+Ew8U/b PO/4SDVvtfv9FAHzBrP7EX7F/iP4NeE/2c/EP7In7MGu/s+eAvEFz4s8C/AnWfgF8KdU+DXg vxVeT+Jrq88TeE/hhfeE5/BPhzxBdXPjTxjcXOs6PodnqM8/izxNNLctJr2qNdd/rP7PXwC8 R/GXwn+0Z4h+B3wf139oPwF4fufCfgX47az8NPBeqfGXwX4VvIPE1reeGfCfxPvtFn8beHPD 91beNPGNvc6No+uWenTweLPE0Mts0evaot17BRQB4Bon7J37LHhn/hen/COfs0/s/wDh/wD4 ag/tf/hpf+xPg38OtK/4aI/4SD/hKf7e/wCF6fYPDlv/AMLb/tv/AITjxr/a/wDwn/8AwkH9 pf8ACYeKftnnf8JBq32v4/8A2hP+HL3wO8CeA/2Ov2rP+HYHwf8Ahl4X2/Fj4Y/ssftCf8Mp fD/wJ4d/tvWPHdivxL8B/A/4j/2R4f0j+1/EGr/E2zXxl4f8MW/2/WNT8d241KW9vfECS/p/ XwB/wTg/4mPwX+NXjDUP9P8AFvjH9v8A/wCClv8Awl3im9/0rxH4q/4Vr+31+0V8C/h1/wAJ Jrc+/U9c/wCEB+CXwo+Fvwd8Ff2ndXX/AAivws+GvgD4e6F9g8JeDvDukacAeP6z+27/AMEN fEfxl8J/tGeIf2u/+CUGu/tB+AvD9z4T8C/HbWfj7+yDqnxl8F+FbyDxNa3nhnwn8T77xZP4 28OeH7q28aeMbe50bR9cs9Ong8WeJoZbZo9e1RbrA0T9rH/ggX4Z/wCF6f8ACOftLf8ABIDw /wD8NQf2v/w0v/Ynxk/Yw0r/AIaI/wCEg/4Sn+3v+F6fYPEdv/wtv+2/+E48a/2v/wAJ/wD8 JB/aX/CYeKftnnf8JBq32v8AX6igD8wPhb/w5e/a38CaF+x18FP+HYH7Tfwy+Fn9p/Fjwz+y x8Lf+GUvjR4E+HO3WNQsdZ+JehfA/wAJ/wDCSeH/AAht8QfFHVbPU/GWn+GNOxrHxF1C3utS +2+LrlNQ+39Z/Z6+AXiP4y+E/wBozxD8Dvg/rv7QfgLw/c+E/Avx21n4aeC9U+MvgvwreQeJ rW88M+E/iffaLP428OeH7q28aeMbe50bR9cs9Ong8WeJoZbZo9e1Rbr5g/4KP/8AEu+C/wAF fGGn/wCgeLfB37f/APwTS/4RHxTZ/wCi+I/Cv/Cyv2+v2dfgX8Rf+Ec1uDZqeh/8J98Eviv8 Uvg741/sy6tf+Eq+FnxK8f8Aw9137f4S8Y+ItI1H7/oA8A0T9k79ljwz/wAL0/4Rz9mn9n/w /wD8NQf2v/w0v/Ynwb+HWlf8NEf8JB/wlP8Ab3/C9PsHhy3/AOFt/wBt/wDCceNf7X/4T/8A 4SD+0v8AhMPFP2zzv+Eg1b7Xz+s/sRfsX+I/g14T/Zz8Q/sifswa7+z54C8QXPizwL8CdZ+A Xwp1T4NeC/FV5P4murzxN4T+GF94Tn8E+HPEF1c+NPGNxc6zo+h2eozz+LPE00ty0mvao119 P18Af8FM/wDSf2XdH8O3P+keH/iB+1//AME4vhP480Kf97o/jb4WfGD/AIKJfss/C34t/DTx dpkm6y8SfD/4o/DLxf4s+HXxF8G6zBe+HPG3gTxR4i8I+JtN1Pw/repafcgHj+s/tu/8ENfE fxl8J/tGeIf2u/8AglBrv7QfgLw/c+E/Avx21n4+/sg6p8ZfBfhW8g8TWt54Z8J/E++8WT+N vDnh+6tvGnjG3udG0fXLPTp4PFniaGW2aPXtUW6wNE/ax/4IF+Gf+F6f8I5+0t/wSA8P/wDD UH9r/wDDS/8AYnxk/Yw0r/hoj/hIP+Ep/t7/AIXp9g8R2/8Awtv+2/8AhOPGv9r/APCf/wDC Qf2l/wAJh4p+2ed/wkGrfa/1+ooA/GHWf2hf+DeLxH8GvCf7OfiH44/8EYdd/Z88BeILnxZ4 F+BOs/Ev9h/VPg14L8VXk/ia6vPE3hP4YX2tT+CfDniC6ufGnjG4udZ0fQ7PUZ5/FniaaW5a TXtUa6+//A3hP9i/9pTxV8Nv23fhr4Z/Zg+P3jbSfD+ueE/hB+154G0b4U/FTxVpvhWx1Hxt 4T8S+Gfht8fdAtte1ez8P2er678RvDWuaN4X8WR6db6jrPjbRr+2S51HXbab6fr4A+FH/Eo/ 4Ka/tueHdK/4lnh/W/2QP+CeHxY1nQtP/wBC0fV/in4o+J//AAUQ+Fvib4l6nplt5Vlf/EDx F8Mvgd8FPh1rvjK6gl8R6v4E+D/wt8I6hqVx4f8Ah/4T0/SAD6A0T9k79ljwz/wvT/hHP2af 2f8Aw/8A8NQf2v8A8NL/ANifBv4daV/w0R/wkH/CU/29/wAL0+weHLf/AIW3/bf/AAnHjX+1 /wDhP/8AhIP7S/4TDxT9s87/AISDVvtfP6z+xF+xf4j+DXhP9nPxD+yJ+zBrv7PngLxBc+LP AvwJ1n4BfCnVPg14L8VXk/ia6vPE3hP4YX3hOfwT4c8QXVz408Y3FzrOj6HZ6jPP4s8TTS3L Sa9qjXX0/RQB8gftCf8ADAvwO8d+A/2xf2rP+GQPg/8AE3wvt+E/wx/an/aE/wCFL/D/AMd+ Hf7b0fx3fL8NPAfxw+I/9keINI/tfw/q/wATbxfBvh/xPb/b9H1Px3cDTZbK98QPL8gaJ+1j /wAEC/DP/C9P+Ec/aW/4JAeH/wDhqD+1/wDhpf8AsT4yfsYaV/w0R/wkH/CU/wBvf8L0+weI 7f8A4W3/AG3/AMJx41/tf/hP/wDhIP7S/wCEw8U/bPO/4SDVvtfv/gr/AInH/BU39pb+1/8A ia/8K5/YA/Ye/wCFff2l/p3/AAgn/C6P2iv+ChP/AAuL/hDftXm/8Ix/wtj/AIUJ8C/+Fl/2 J9h/4Tv/AIUv8J/+Ep/tX/hXPg/+x/v+gD8YdZ/aF/4N4vEfwa8J/s5+Ifjj/wAEYdd/Z88B eILnxZ4F+BOs/Ev9h/VPg14L8VXk/ia6vPE3hP4YX2tT+CfDniC6ufGnjG4udZ0fQ7PUZ5/F niaaW5aTXtUa69f0z9rH/gi98YP2jvhb8UtG/aW/4JgfFH9rq2/s/wCE/wAFPiLpnxk/ZS8b ftHW/wDwl91rvh3Svhp8LfF1r4j1P4mxf8JRe/EDxNoWn+DfCeoL/bd14213TLbTbmbxJqEF 7+n9c/4s8J+FfHvhXxN4F8deGfD/AI08E+NPD+s+E/GPg7xZo2neI/Cvizwr4j0650fxD4Z8 TeHtYtrzSNe8P67pF5eaXrOjapZ3Wnapp11c2N9bT208sTAHkGifsnfsseGf+F6f8I5+zT+z /wCH/wDhqD+1/wDhpf8AsT4N/DrSv+GiP+Eg/wCEp/t7/hen2Dw5b/8AC2/7b/4Tjxr/AGv/ AMJ//wAJB/aX/CYeKftnnf8ACQat9r5/9j3TvCug/BBfCngX9mbw/wDsh+CfAfxg/aY+HHg7 4H+E/B+neAfCtn4V+G/7Svxb8CeHvid4Z8JaP4O8B6RpHh/9oPSPDtn+0Hoy6X4dOnXmnfFC 21Gx8QeMba7i8Ya75/8A8EyfFnirx7/wTb/4J8+OvHXibxB408beNP2IP2UPFnjHxj4s1nUf EfirxZ4q8R/AbwDrHiHxN4m8Q6xc3mr694g13V7y81TWdZ1S8utR1TUbq5vr65nuZ5ZW9/8A gfo3xl0HwXrVj8dvFnh/xp42n+MH7Qus6HrHhm2gtdOs/g14j+PvxL8Q/s5+E7mK38M+E428 QeAv2fNU+GHgXxZctpd1PeeKvDms3l14m8aXM83jHXQD2Cvzg/aM8WeFfhD/AMFC/wBgj4r/ ABP8TeH/AAJ8O/Hvwf8A2xv2L/CHirxNrOnaXp2uftP/ALQ/j79ij4u/BD4QWwuLlbmLxB8T vBP7KHx2k8J3t1bweH9S8VeE9G+Ha6wvxE+Ivwz8K+MfP/hd/wAFRYPHHw9+HXjPU/2e/EGp eKf2k/D/AMC/ib+x38Evg38Yfg149+Mvxs+En7Snwz+Nnxs+Fw8faB8UfE37P/hv9nf4waJ8 G/2bPjr8Q/ih4f8AiL4tm/Z4MHgK98D/ALPP7Vn7SfxWt/EXw/8ADXxB4n/4OFf2QPjF4EuN K8KfsC/t/wD7YfwS+N/2z4deE7f4W/s/fs//ABh0f9pPwJ4+1j9sX4e20+hfAHWf2i7b4269 8P8A4iaZ+w5+1ndan4d+InwU8N6xpfgT4c6hqHxP8I+FdM8U+GYddAP6PqK/mC8d+Nv+CI3g H9r9v2ONU/4Ih/D9/FsfxA8B+B5PiLqH/BP39hjwD4EfR/H37QH7Pf7K2m/GPTPCPxb8V/Dz 9ofxJ+z+P2h/2l/AHws0L40+FvgVrngT4r6xofxS1j4Ear8V/CXwo8e+ItD8/wDiB8e/+CF3 ww8CfE/40+Mf+CHvw/079nL4Y/s//CH9qOX9oeD9h/8A4Ju3/gTxl8Cf2m9Y+JHhT9kPxz4R 8F2Xxan+PSf8NVeOvhnqPgf4deGfGHwc8I+Mfh3rGveHdV/aZ8PfATwY2veKdBAP6va/MD/g qR/wqz4o/Dr9n79jPxd/wr/xr8QP2sv2v/2Rv+EO/Z+8a/8ACOap/wALp+Fn7M37U/wQ/am/ a0+2+EvE2/Rdc+H/AIB/Zl+FHxF8ReP/APhIoh4c1bzvDnwyg/tj4gfE/wCHngvxf+IMn7S/ /BIHRPE/gj4deJv+Dcn+1/ib4y+IGsfD3VdD+D/7BH/BP/4n+BPg/wCI9X/4KCftIf8ABO74 KeD/AI9fG/UPGPgT4P8Aww+IHxe+MH7OOswWlrc+LtX+FllrGvQ+HfCfxi+IllpF14puP0f+ EX7UP7F/7MPwz/4KH/E39jv9gj4P/Am2/Zc/Ygsf2rvi14V+HHgf4U/s+eKviH8TPhT8Qv8A gop8IvHn7MvxOPwj8B634Wh8QfAX4rfsS/FHwEvxS8O+KPjT8PdX1Hx54g174XXHiTwTa6b4 q+IgAfsw/wDBu1/wTq/ZJ+Mv7Q/xG+EHgTxB4e8LfGfw/wDBC2+HOhaR48+KHhr4y/sreKvh pB8StL+JWs/s4/tg+F/iHo/7Ufw58P8A7QOh+MPDVh8SvDOhfErT9R1aDRPF/hfX/Fnif4U+ ObD4YeCft/8A4Yu+Lvgn5fgL/wAFCP2v/h/4f0H/AImHgP4SfFmf4J/tYfCy21iL/iZNpnxL 8e/tCfCLxf8Atz/FH4f+JPFDXeo+MtCm/be8L+O7bw5q+peB/g/8Uvgz4f0zwJH4J+IPgj/w Xm+Enx4/Zu+FX7Rnw8/ZP/af+INt8VPEHhy2f4f/AA4vv2eH8VfDHwr8cP26fiz+wX+xzrPx O1D40/HT4EeFj4g/ab+K3wj8SW6+GfhTrnxX074M6jpPiCH4qeLNG8Ew+DviR499/wD2A/8A gq34V/b08aad8OfD37Lv7T/w61ez/Zg+AH7Q3jr4vaz4J07Xv2R9F8VfHj4Bfs1/tDWf7Pnh P9oax1ewufF3xg8N+Cf2nfB1/c+HtY+GvgbUdS0TQvE3iiLTLPSItLbUwD2D/jab8P8A/owD 9rb+1v8As4r/AIJ3/wDCv/sH/i0H/hb/APwlf23/AKod/wAK/wD+Eb/5qX/wm3/Fvz/htH4u +Cfm+PX/AAT3/a/+H/h/Qf8AiX+PPi38J4Pgn+1h8LLbWIv+Jaup/DTwF+z38XfF/wC3P8Uf h/4k8UNaad4N12H9iHwv47tvDmr6b44+MHwt+DPh/TPHcngn7/ooA+IPCf8AwUo/YM8WeKvD Pw5l/aq+D/w8+Mni7xBo3hPRP2ePjv4lT9nD9qBvFXifUbbTPCHhnVP2Xvj/AA/DT9oPw94g 8cyaho9/4A0bxD8NdL1Hx74f8ReFvFHg621vw34q8Oarqn2/XP8Aizwn4V8e+FfE3gXx14Z8 P+NPBPjTw/rPhPxj4O8WaNp3iPwr4s8K+I9OudH8Q+GfE3h7WLa80jXvD+u6ReXml6zo2qWd 1p2qaddXNjfW09tPLE3xB/w64/YT0f8A5JP8DP8Ahlf7T/yH/wDhhj4m/GL9gT/hO/J/5BX/ AAtH/hin4g/AT/hbH/CMebqX/CE/8LL/AOEr/wCEE/4SHxd/whv9hf8ACZeK/wC2AD7/AKK+ AP8Ahkv9pjwJ/p3wR/4KMftAf8SL/Q/AHwt/aj+Gn7Pf7SfwJ0fw5/yDLLw5451Dw58NfgJ+ 218WP+EY8NSvF4Z8a+Lf26f+Fp6x4x0vw94z+Mvj/wCMX/Fa6F47P+Ez/wCCmvw7/wBE8RfA j9kD9pvw/wCHP+JhrvxE+E/x5+J/7M/xT+Imjr/xNtT0z4afsn/FL4QfHH4ZeHfiBYWUs/g7 wboXxF/4KHad4E+IniPS9N8VeLvil8CvD/i7UNH+HYB9/wBFfAH/AA31/wAIl/yX39iv9v8A /Z//ALQ/5FP/AIxx/wCGwP8AhLfsn/Id/wCUaPjL9uP/AIV3/YP2nRv+S1f8Kv8A+Et/tr/i 3H/Ca/8ACM+PP+ES9g+Cn7a37I/7RfirUPh58Ff2jfg/49+K2g+H7rxN4x+CWm+ONEs/j78N tO0vUdK0PxDbfFv4Caxdab8ZPhD4g8HeJNc0rwl498J/E7wP4T8VeAPGl5H4M8aaNoXilZdI jAPp+iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACvgD /gpz/wAS79kTVvH97+58JfAj9oD9ij9qP4rat/rP+EV+BP7Jv7bH7PX7S/7QHjn7BF5mp65/ wgPwS+FHj/xr/wAIz4cstY8Y+Kv7B/4RzwV4e8R+LdU0XQdR+/6+YP23fgp4q/aU/Yv/AGu/ 2c/AuoeH9J8bfH79mD4+/BTwdqniy61Gx8K6b4q+Knwp8WeBfD2oeJr7R9K17V7Pw/Z6vrtn cazdaXoes6jb6dHczWOlajcpFZzAH0/XwB+zP/xRP7af/BSj4W6r/pHiD4gfED9mL9tbRrzT /wB7o9t8LPjB+zF4I/Y68M6Bqdxc/ZL2H4gWPxN/4J2/GvXdd0q10+98OW3gTxR8LdT0/wAV 6n4g1vxZ4Y8E/T/7PXxr8K/tKfAL4H/tGeBdP8QaT4J+P3wf+Gnxr8HaX4stdOsfFWm+Ffip 4L0Xx14e0/xNY6PquvaRZ+ILPSNds7fWbXS9c1nTrfUY7mGx1XUbZIryb5g/5J//AMFTf+gt /wANbfsAf9eH/Cv/APh3f+0V/wBvv/CV/wDC3/8Ah6D/ANS3/wAK/wD+FHf8zt/wsv8A4t+A ff8ARRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB4/8NNZ+MuqeNP2hbH4n+E/D/hzwT4c+ MGi6N+znrGjXME+o+Pfg1P8AAL4H+Idc8WeLIofE2uyWfiCz/aD1747eBba2utL8Fzt4V8F+ GbxfDN1bXVv4x8WewV4B8G9E/sr4i/tY3/8AwvT/AIW3/wAJN+0B4c1v/hAP7X/tL/hl/wCz /ssfs0+HP+FF/Y/+Ep8Qf8I//wAJB/wj/wDw0v8A2R/ZPgfzv+GiP7e/4Ra7/tv/AITXxh7/ AEAFFFFABRRRQAUUUUAFfAH/AATT/wCTdfiN/wBn/wD/AAVi/wDXpv7ZFff9fEHiz9jDW38V eJtd+A/7YH7T/wCyN4b8aeINZ8c+LPhZ8CNG/ZH8R/DPVPiZ4r1G51bx38SdL0X9pj9lT9of V/AniD4i6vOfEvj/AEP4ba/4M+Hviz4hXXin4v6t4Jn+MnxO+LXxB8egH2/RX4w/tu/CH9rT 9mv9i/8Aa7/aM8C/8FUv239W8bfAH9mD4+/Gvwdpfiz4Xf8ABMO+8K6l4q+Ffwp8WeOvD2n+ JrHR/wDgnRoOr3nh+81fQrO31m10vXNG1G406S5hsdV065eK8hP2IvhD+1p+0p+xf+yJ+0Z4 6/4Kpftv6T42+P37MHwC+NfjHS/Cfwu/4Jh2PhXTfFXxU+FPhPx14h0/wzY6x/wTo17V7Pw/ Z6vrt5b6Na6prms6jb6dHbQ32q6jcpLeTAH0/wD8FLP+Tdfhz/2f/wD8Enf/AF6b+xvX3/Xx B4T/AGMNbTxV4Z1348ftgftP/tc+G/BfiDRvHPhP4WfHfRv2R/Dnwz0v4meFNRttW8CfEnVN F/Zn/ZU/Z41fx34g+HWrwDxL4A0P4k6/4z+HvhP4hWvhb4v6T4Jg+Mnwx+EvxB8Bfb9ABXwB /wAFLP8Ak3X4c/8AZ/8A/wAEnf8A16b+xvX3/Xn/AMUvhb4E+NHgTXfht8SdC/4SDwl4g/sy e5toNT1jw/rGlax4f1jT/E3hPxd4R8WeGdQ0fxb4E+IHgTxbo+h+Nvh18RfBOueH/Hfw58d+ H/DvjnwN4i8P+LfD+jazYgHoFFfAH/DG/wC0V/0li/b/AP8Aw3P/AASy/wDpadfmB+1Te/tu /A7/AIKT/wDBKX9jrwn/AMFQ/wBr/Ufhl+3R/wANz/8AC29d8RfCT/gmpd+O/Dv/AAzJ8BfD vxS8Bf8ACutT03/gn9pHh/SP7X8Qavc2fi7/AISbwx4u+36OkFvo39gXqyahKAf0fV8AfDn/ AJSm/tkf9mAf8E0//Wiv+CsVH/DG/wC0V/0li/b/AP8Aw3P/AASy/wDpadfQHwL/AGe9H+Cv /CU+INT8efED43fGD4gf2JB8SPj98Ym8CS/FPxzo/hD+14fh/wCEbq3+GHgT4YfDLwb8P/h3 Za9rq+D/AIdfC34ceAfAln4j8UfEL4nah4d1P4wfFv4vfELx6Ae/0UUUAfAHw5/5Sm/tkf8A ZgH/AATT/wDWiv8AgrFX3/XzB8a/2YoPil4q0/4lfD740fGD9l74yQeH7XwNrnxf+AcHwauv FXjr4Z6fqOq6/pHw2+IXhr49/B/46fCnxl4f8L+Kda1bxR8Ptc1r4c3HxC+Feo+I/iHYfCzx t4L8N/Gb426F8SPH/wDhjf8AaK/6Sxft/wD/AIbn/gll/wDS06APv+iv5wf+CY17+27+2j/w 8J/4Wl/wVD/a/wBA/wCGTf8Agp/+1j+xT8Ov+EA+En/BNTS/7a+FnwI/4QH/AIRHX/Gv/CRf 8E/vFX9o/EDUf+Eq1D/hI9V0L/hHPDl55Nn/AGZ4U0fy5/tH6f8A/DFXxo1H/iX+MP8Agp9+ 3/4x8JX/APofinwj/Z37Avw1/wCEq8OXX7jW/Dn/AAsX4F/sJfCj42+Af7c0x7rTP+E1+Dvx S+GvxT8K/av7d+H3j/wd4tsNI8RacAH/AASd/wCUWX/BNP8A7MA/Y3/9Z1+HNewfsiaN8GtB +FPiyx+BPizxB408Ez/tP/tu6zrmseJrae11Gz+MviP9tD4++If2jPCdtFceGfCcjeH/AAF+ 0HqnxP8AAvhO5XS7qC88K+HNGvLXxN40tp4fGOu+/wDhPwn4V8BeFfDPgXwL4Z8P+C/BPgvw /o3hPwd4O8J6Np3hzwr4T8K+HNOttH8PeGfDPh7R7az0jQfD+haRZ2el6No2l2drp2l6da21 jY20FtBFEvkH7NOt/wDCQfDrxHf/APCi/wDhnf7P+0B+1jon/CAf2R/Yn/CQf8Iz+1P8ZPDn /C9Psf8Awi3g/wA7/hqD+yv+Gl/7X/sm7/4SD/hbf9vf8JT44/tL/hNfEAAan+yd+yxrfgT4 pfC3Wf2af2f9X+GXxx+IGofFj41/DrU/g38Or/wJ8YPinq+saF4i1X4l/FLwjdeHJfD/AMQP iBqfiDwv4Z13UPGXizT9X8R3useHdC1O51KW90jT57fn/Hv7EX7F/wAVNO1LR/if+yJ+zB8R 9I1nxBH4s1jS/HvwC+FPjDTtW8VReKvi346i8TalY+IfCeo2194gj8bfH747eMY9ZuopdRTx V8avi34hW5Gr/Efxjeaz9P0UAfIGpf8ABPz9h3V/in4N+Neofsmfs/3HxN+H/wAQPiX8X/CP ib/hV3hKL+yPjZ8YPEfwn8WfEX48/wBjQaZF4fv/ANoDxF4g+B3wt1D/AIXvqelXvxd0j/hF /suheM9Mstb8RW2r9BdfsRfsX32nfGvR779kT9mC80j9pTxBpXiz9ovS7r4BfCm4074/eKtC 8Vah460PxN8a7Gbwm9t8VPEGjeNtW1TxjpWs+Oote1HTvFWpah4hs7mHV7y4vJPp+igD5A0z /gnt+wLomsfC3xFo37D37IGkeIPgd/Z//ClNd0z9mn4L2GsfB/8Asjx3rvxS0r/hVup2vgqK 9+H/APZnxN8UeJviLp//AAic+kfYvHfiLXfF1t5XiDV9Q1C49fX9nr4BJp3xH0dPgd8H10j4 x+H/ABB4T+Lulr8NPBa6d8VPCvizxV8TvHXirwz8R7EaKLbxx4f8S+NvjZ8ZvGPiDRvE8Wqa drPir4ufE7xDqNtc6v498VXmrewUUAfMHxO/Yi/Yv+NmneH9H+M37In7MHxc0jwn4g+I/izw rpfxO+AXwp8e6d4a8VfGPxU3jr4u+JvD9j4q8J6tbaN4g+KnjZ38Y/EfWdOittR8ceKmbxD4 nudU1djeHoPh1+yd+yx8H/Hc/wAUvhJ+zT+z/wDC74m3Pw/8O/Ce5+Ivw6+Dfw68E+O7j4We ENH8I+HfCfw0n8XeGfDmmeIJfh/4X8P/AA/8BaF4d8Gyag3hzRNH8E+EdM03Tbay8N6NBZe/ 0UAFFFFABRRRQAUUUUAFeP8Axr/Z6+AX7SnhXT/Av7RnwO+D/wAfvBOk+ILXxZpfg741/DTw X8VPCum+KrHTtV0ex8Taf4e8daLr2kWfiCz0jXdc0u11m3s49Rt9O1nVbGG5S21G8im9gooA +AP+HaX7M/hz958Eb39oD9lf+yv9M8AeGP2XP2ov2hPgv8CfhZ4jh/0yy8R+Bv2OvDnxG/4Y l/5GXf438TeCvFv7N/iv4WfFPxjfeIdY+MvgD4jf8Jl41t/EZ/wzx+3Z4E/5JP8A8FFf+Fjf 2r/yH/8Ahuf9kb4O/Gj+x/sP/IK/4Vd/wxTrf/BNf/hGv7Q+2al/wm3/AAsv/hdH9sfYfCP/ AAhv/Cuf7K8V/wDCd/f9FAHwB/wub/goJ8MPl+KX7F/w/wD2hvD9l/xTtn4o/Yp/aL8MW/xT 8ZaxbcW/xF1/9nj9sXS/2aPhl8Gfh/4hstP1DUdV8I6F+29+0h47+HfiPW/CvgfTJ/jB4fXx P8XNBP8Ah418IvC3+g/Hr4Qftf8A7MniDTP3/jyL4s/sm/GzxR8LPhTo7f6avi74l/tefs9+ Ffjj+wx4d+H9h4XltPGnjL4iw/tQaj4E+FPhyXUk+MHiL4f+IPCPjvQfC33/AEUAeAfAv9rH 9lj9qD/hKf8Ahmj9pb9n/wDaI/4Qf+xP+E1/4UX8ZPh18W/+EP8A+Em/tf8A4Rv/AISn/hAP EfiD/hH/APhIP+Ef17+xP7W+yf2r/Ymr/YPtH9m3nk+/14B8dP2Tv2WP2oP+EW/4aX/Zp/Z/ /aI/4Qf+2/8AhCv+F6fBv4dfFv8A4Q//AISb+yP+Ek/4Rb/hP/DniD/hH/8AhIP+Ef0H+2/7 J+yf2r/Ymkfb/tH9m2fk/P8A/wAO8vAngz9/+zV+0F+1/wDskXq/8SyzsfhP8fdY+KXws8Ne BB89v8Lfhp+y/wDti6V+1H+yL8FPh/o01roMPg3T/gj8AfhzrHw38OeG9N+Hvw213wh8MtQ8 T+C/EAB9/wBFfAH/AAqr/go58Pf3HgD9r39n/wCO/hLw5/xMtJ0H9qP9lfVNA+O3xM8v/ibX /g3xz+0v+zR8ZvhR8EvAP9uanJeeFfDPxL8Ff8E9Ne/4Vn4Ok8Pan4j+E/x38W+HNev/AIhH /DQ/7dngT/krH/BOr/hY39q/8gD/AIYY/a5+Dvxo/sf7D/yFf+Fo/wDDa2if8E1/+Ea/tD7Z pv8AwhP/AArT/hdH9sfYfF3/AAmX/Cuf7K8Kf8J2Aff9FfAH/D0D9izSP9J+KXxF+IH7Mnh9 /wBxZ+Pf21v2bf2nf2F/hZq+sN+8t/COgfFv9sX4OfA74ZeIviBf2UWoazpXw60LxZqPjvV/ DmgeK/E2meHbvw/4R8T6lpH1/wDC34sfCz44+BNC+KXwU+Jfw/8AjB8MvFH9p/8ACM/EX4W+ MvDnxA8CeIv7E1jUPDus/wBheLvCepav4f1f+yPEGkaroWp/2fqFx9g1jTNQ0y68q9srmCIA 9AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAPgD/AIJcf8Sb9hP4GfCb/j5/4ZX/ AOFm/sMf2/8A6n/hO/8AhgT4xfEH9in/AIWj/ZX73/hGP+Fsf8KE/wCFl/8ACE/2l4h/4QT/ AISv/hDf+Eu8Zf2F/wAJXrB+0x/xRP7af/BNf4paV/pHiD4gfED9p39inWbPUP3uj23ws+MH 7MXjf9sXxNr+mW9t9kvYfiBY/E3/AIJ2/BTQtC1W61C98OW3gTxR8UtM1DwpqfiDW/CfifwT +cHxc/bv1H/gmh+3n+0R+yTo/wANPEH7Tnin9ufw/wCF/wBrX/gnX+yv8DbPwrovipv2h/Eb j4UftPfBPxzczfFDXbb4F/B/xz428FRft0a7+0x4x+C/w2+Ek2o+Nf29fiB4h8VfE34reAdW 0bxR6B+1B+xf/wAFgf2x/hmn/CX/ALb/AOzB+y9q/hPxB40+Lfw9/Zy/Zt/Z+vfHvhXU/jL8 KviFY/GL9gqT4wftjftFjxx4k8TeH/g98ZPhf8EPH3xW1L4Z/sV/CCD4gac3xS8A3HgLVNI1 Pwpq+iAH7vUV/OD+wV+wp4j/AGl/Anwp/wCCgHh//gq5/wAFvvh/8TfiR/wnWt/Eb4G/FL9o b4WeIPAnwZ+O0WseMfhl+0V8C9d/Zs+M37EHh34Pxf8ACjvjBYfEf4Y6ZpDfs/eF/B3h7WPB mn+JPhj4W8NWWmeELrT/ALA/Zv8AD/8AwU/+B3gTWPEfiv8AbJ/Z/wD+Cwfh+0+IHjfSvEFl pnwW8AfsWfGzw7/wgesSeCviP4M+Fvj/AOGPxD+In7OXxE+IHw78Z/Dvxn4A0/4D/F7wV8BP t/xd8T67ZfFT9sf4ReH/AIdt4clAP1+orx/4KfH74NftF+FdQ8Y/BX4heH/HukaD4guvBnjG z02aez8VfDb4haXp2lap4h+Ffxb8C6xb6b42+EPxg8HW2uaVF49+EPxO8PeE/iZ4A1G8j0fx p4U0LV1lsY/YKACivAP2o/jp/wAM4fAnxz8WLLwt/wAJ94t07/hGfB/wp+Gn9t/8Ir/wtn47 fFfxj4e+E37P/wAHf+Eyl0jXdM8B/wDC3vjb438AfDT/AIWF4j01/B3gD/hKv+Ey8a3WneEt D1rUrT5//wCHcP7OPxP/AOKs/bT8AfD/APbo+MGrf8TDXfFH7R/gW1+Jfws8G6xd8anpn7Mf 7O/xS1b4mfDL9lX4fvZQaF4Zk0L4XWyeO/iJ4c8DfD/Wf2k/il+0H8YNA1D4ua8Aff8AXzB+ 0z+1T4V/Zp07wdZn4dfGD48fFb4l+INO0D4Zfs+fs8eEdO8c/GXxvBL4q8H+FPFHjcadr3iL wd4J8A/B/wCF9z488K33xc+OXxd8dfDr4NfDaDxD4X0vxV470/xT458BeHfFPj//AA6x/wCC fekf6T8Lf2Xvh/8AsyeIH/cXnj39imfxP+wv8U9X0dv3lx4R1/4t/sda/wDA74m+Ivh/f3sW n6zqvw613xZqPgTV/EegeFfE2p+HbvxB4R8MalpHj/hn4EfDP9n7/gp5+zLZ/D7S/EGo6v48 /wCCcH7Z/hPxZ8Qfi34/+IX7Qfxl1jwr8Cf2tP2MvGvww8MyfHL4++KfiZ8ZLXw/oXiT9rn4 5X2paNY+OrXTvGEGr+AtL8a23iLSPgh8DrH4cgHsH/COf8FTfFv/ABUP/C5P2AP2f/7Q/wCa Rf8ADNP7RX7YH/CJfZP9B/5OL/4ax/Yc/wCFif299m/4Sb/k1z4X/wDCJf21/wAIN/xWv/CM /wDCxPFp/wAND/t2eH/+KU8Yf8E6v+Em+IGt/wDIreMvgF+1z8HfHH7LHh/+0v8AiW6J/wAL q+Jfx00T9l/9prwf/ZWtQ3Wq/Ef/AIU7+xT+0R/wj/w6uNG1/wCH3/C2/iBd6v8ACfw/+QP7 IP7eGqePvgT+wZ8UPCX/AAWA/wCGxv2x/jZ/wwh/wuP9gb+2/wDgnH4i2f8AC/PGPwY8Pfti f8Wf/Zv/AGbPhx+1b4a/4Zb+Fnjn4y/Gf5PiZb/8Ko/4U7/wlHxu/wCEs+G/hH4h+H9c/Z74 bf8ABQL4BfEjTvBOsJP4g8DaRrH7MHjn9qn4u6p8RZPBfhnTv2Q/Cvw68VaH4F8VfDr9sS+H jO+tvgD8YNO8bR/GbwdP4R8Tyy6daeKv2S/2uPD2o+IrHV/gP4qswAc//wAM8/tp/E//AIqz 4pft7fED9nnxBe82fwk/Yp+Fv7MVx8LPBuj3P/Eyt9A1/wAe/ti/s4ftL/E34zfEDw9e6hqH hnVfjRoVt+zf4E+InhzRPCus6Z+yr8H/ABA3iePXj/hmn9rv4e/8Vr4A/wCChP7QHx38W+HP +JlpPwa/aj8FfsUaB8CfiZ5fyX/g3xz4t/Zo/Ye+FHxt8A/25pkl5Z+GfiX4K8R69/wrPxjJ 4e8f+I/hP8d/CXhzXvgj8QvP/wDgmL+0h+0d+0vY/toeJv2kNH/4Qy98L/tf2GmfBb4VX3gi 6+H/AIx+DP7OPxI/Y2/Y/wD2jfg58Lfi74b1WOXxBYftAeHfD/xxkuf2i9P1jWfEtr4e+O2p /ETwn4I12X4ZeH/A9hp/6f0AeAfs3/tL/Cz9qbwJrHjX4Y6tuvfBPxA8b/Br4veANTv/AA5c +O/gf8dvhbrEnhz4qfBH4pWfhTXvFHh/TPiB8P8AxBE1lqD+H/EfiTwd4o0e50Lx/wDDjxb4 2+GXi/wZ418Q+/18QfAC58Kt+2F+35Z/DfRvEEHhuDxB+zXc/GjxDc+JtOuvCuqfthXXwM06 Lxzo2jeDtU8J2fjzQvEGhfseWf7Bd94m8Taf468R/AzxZp3iPwnpfw/8J+C/jJ4L/aV1jx79 v0AfMHwC1n4Nap8Vv23bH4YeE/EHhzxt4c/af8J6N+0ZrGs3M8+nePfjLP8AsX/sieIdD8We E4pvE2ux2fh+z/Z8174E+Bbm2tdL8FwN4q8F+JrxvDN1c3Vx4x8WfT9eP/DTWfjLqnjT9oWx +J/hPw/4c8E+HPjBoujfs56xo1zBPqPj34NT/AL4H+Idc8WeLIofE2uyWfiCz/aD1747eBba 2utL8Fzt4V8F+GbxfDN1bXVv4x8WewUAFFfnB+0z/wAFE/Cvwy+Mvg79j79mTwn4f/a+/bw8 beINOhvP2a/C/wAT9O8Iad8BfhnbQeD/ABB46+P37YfxI0vw18Sbn9mn4P8AhbwR438M6r4Y uNe8AeJPiF8Z/FXi/wACeBvg18PfG1/4kvtR8P8AQf8ADPP7afxP/wCKs+KX7e3xA/Z58QXv Nn8JP2Kfhb+zFcfCzwbo9z/xMrfQNf8AHv7Yv7OH7S/xN+M3xA8PXuoah4Z1X40aFbfs3+BP iJ4c0TwrrOmfsq/B/wAQN4nj14A+/wCivxh+Cn/BHvxp8AfFWoeMfAv/AAWO/wCCz2u6vqXh +68M3Fn8a/2l/gF+0p4Vj0681HStUmudP8C/tGfsofFTwTpPiBLnRrOK18WaX4es/FVjp02q 6PY6zb6RruuWOo9B41+KX/BQT9mTw5e/Fn4U678P/wDgrP8AssfDv/hP9H+Jnhnw5pnhj4d/ 8FHNO1j4f/FPw54T+KEngDWfgxp9l+yL+1b8QPhLNpX7QHhy9/Zv0X4I/sW+O11T4d+CvhVF 43+Inxni8UXPi4A/X6ivAP2aP2qv2cf2yPhZpPxr/Zc+NHw/+OPwy1f7BB/wk3gDX7XV/wCw tYv/AA5oPiz/AIRHxro2YvEHw/8AiBpnh/xR4e1DxH8OvHOleHfHfhT+17O18TeHdIvZfsw9 /oAKKKKAPgD/AIKxf8osv+Cln/ZgH7ZH/rOvxGo/4JO/8osv+Caf/ZgH7G//AKzr8OaP+CsX /KLL/gpZ/wBmAftkf+s6/Eaj/gk7/wAosv8Agmn/ANmAfsb/APrOvw5oA+/6KKKACiiigAr8 Af8Agof/AMp1/wDg3V/7y5f+seeCa/f6vwB/4KH/APKdf/g3V/7y5f8ArHngmgD9/qKKKACi iigAooooA/AH/ggX/wA5qP8AtP8Af8FG/wD3jdfv9X4A/wDBAv8A5zUf9p/v+Cjf/vG6/f6g Arx/4H6N8ZdB8F61Y/HbxZ4f8aeNp/jB+0LrOh6x4ZtoLXTrP4NeI/j78S/EP7OfhO5it/DP hONvEHgL9nzVPhh4F8WXLaXdT3nirw5rN5deJvGlzPN4x132CvmD9kTRvg1oPwp8WWPwJ8We IPGngmf9p/8Abd1nXNY8TW09rqNn8ZfEf7aHx98Q/tGeE7aK48M+E5G8P+Av2g9U+J/gXwnc rpd1BeeFfDmjXlr4m8aW08PjHXQD6fooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAr5A+KX/BPz9h340eO9d+LfxJ/ZM/Z/8QfG3xB/Zk9z+0FB8LvC Xh/9o7StY8P6Pp+g+E/F3hH9onwzpmj/ABt8CfEDwJpmj6HH8OviL4J8e+H/AB38Obrw/wCH dS8DeIvD+p+H9GvLH6/ooA+AP+GBf+ES/wCSBftqft//ALP/APaH/I2f8ZHf8Ngf8Jb9k/5A X/KS7wb+3H/wrv8AsH7TrP8AyRX/AIVf/wAJb/bX/Fx/+E1/4RnwH/wiR/Zv/BU3wJ/xN/8A hMv2AP2qPtP/ABLf+Fe/8K0/aK/YE/sfzv8ASv8AhMv+Fxf8LY/4KUf8JL/Z/wBj/sT/AIVp /wAKL8Kf2x/wkP8AwlP/AAtjQv8AhDf+EP8AHf3/AEUAfAH/AA1p+0x4E/0H43f8E5/2gP8A iRf6Z4/+KX7LnxL/AGe/2k/gTo/hz/kJ3viPwNp/iP4lfAT9tr4sf8Ix4alSXxN4K8JfsLf8 LT1jxjpfiHwZ8GvAHxi/4orXfHZ/w9H/AGE9H/5Kx8c/+GV/tP8AyAP+G5/hl8Yv2BP+E78n /kK/8Ku/4bW+H3wE/wCFsf8ACMebpv8Awm3/AArT/hK/+EE/4SHwj/wmX9hf8Jl4U/tj7/oo AKK+AP8Ah1j/AME+9I/0n4W/svfD/wDZk8QP+4vPHv7FM/if9hf4p6vo7fvLjwjr/wAW/wBj rX/gd8TfEXw/v72LT9Z1X4da74s1HwJq/iPQPCvibU/Dt34g8I+GNS0g/wCGLvi74J+X4C/8 FCP2v/h/4f0H/iYeA/hJ8WZ/gn+1h8LLbWIv+Jk2mfEvx7+0J8IvF/7c/wAUfh/4k8UNd6j4 y0Kb9t7wv47tvDmr6l4H+D/xS+DPh/TPAkfgkA+/6K+AP7S/4Km+BP8AiUf8Ib+wB+1R9p/4 mX/Cwv8AhZf7RX7An9j+d/ov/CG/8Kd/4VP/AMFKP+El/s/7H/bf/Cy/+F6eFP7Y/wCEh/4R b/hU+hf8Ib/wmHjs/wCG7vEfhX/iYfHT9gj9v/4EeEpv9D07xd/wqb4WftZf2j4jk/f2nhz/ AIV1/wAE6Pjh+2j8bdF+2aZb6vqf/Ca+KfhboHws07+x/wCwtb8f6X4t8R+B/DvioA+/6K+I PCf/AAUo/YM8WeKvDPw5l/aq+D/w8+Mni7xBo3hPRP2ePjv4lT9nD9qBvFXifUbbTPCHhnVP 2Xvj/D8NP2g/D3iDxzJqGj3/AIA0bxD8NdL1Hx74f8ReFvFHg621vw34q8Oarqn2/QAUUUUA FFFFABXgH7SHx0/4UP4E0fVdG8Lf8LE+JvxE+IHgj4O/BT4Ww63/AGDdfEP4p/ETWI9M0q1u 9QtdI8UeINM+H/w/8PxeJvjT8evGHhPwP8RPEfwp/Zx+GHxg+Mdt8PfGVl8O9Q0K89/r84NG tvFXx9/4KXeLPFD6z4f1L9nz9gX4P23wr0nwxceGdRuNRk/bz/aU0nwz8SviD4rmv9a8WR6d p3iD4BfsX33wZ0H4e+M/DHwyme+8K/t7/H7wFp3xelkt/in8OdOAPmDXf+CVP/Cn/wBnHUPi V4C8SfED9pj/AIKT+EP2gPhb+374s/aX13xf/wAKk+Lv7Y/7THwKtdTsLn4Iahr2jeK/DfgX 4N/s/wDxk+AviT4t/sO/C34PalJ4j/Z7/Zl+Cfxu1PVJPAXj7WNL8Tat4z/T/wDZV/aX+Fn7 ZH7OPwX/AGo/gpq39r/DL44/D/QPH/hnz7/w5f6xoX9r2o/tnwV4u/4RPXvFHh/TPiB8P/EE Wq+BviL4c0/xDq//AAinjvw74i8M3V7Le6Rc49/r8oPH8nir/gm/8Zfjv+1R4h8e+INW/wCC Z/xL8P8Ain4ufHf4WeH/AISaj458QfsUfH2wg0vVvF/7Q/wy0X4UabJ431H9mD4/W1j4x8Zf tWeF9H8A/E/xp4E/ag8Qj9qOUaf8MPit+1V8QfhmAeQftteAP2p/2RvHf7ZX7V37JPjX4f8A hfwZ+2F+z/4c8K/EzWvi14j+IsHgT9kP9sn4f6Pb/Cn4Wf8ABQvxZLeWXxx8C+Hf2f7D4Cy6 F4O/aag8Pfs26nY6TrH7On7M3jf4x6n4V/Zyl/ab/aA+Bf4g/wDBpr+y9+31+yn47/bz8Aaz 4s/Z/wDHH7Ivw/8A2v8A4ufsm/Gvw4vxT+NEXjvwL+1P+y/o+m2eq/F79nvwVdfDFvhl4k+H /wAUbLxf4Z8FeO7jxZefDL4i+KNH8L+A/Edzd6ZD8JdP8AeP/wB/vAH7cn/BRz49/FPxrZ/A r/glN/wiX7Mun/8ACR/8Kt/aS/bi/as1T9j/AMR/Fj/hEvEdn4O1DzP2UdM/Za+Pf7TXwn/4 SfWovEviP4a/8Lb8AeEv+En+Fmi6X418Qf8ACFa14t0LwRL+BP8AwR88F/8ABX3wTd/8FNNG /wCCeHhT/gmR8LfhJoX/AAWH/bO8F/Ej4KftB+KfjbrPw2+E3jDwhL8MrWfwp+yzpXwB/Z4+ D+tW/gfRPDN7pnhNfFPxE8TNoXizQfCfw9tvBH7PH7Ot34b8eah8YwD+nX9sX9nv4u6lrFn+ 1n+yf48+IHhL9pr4O/D+4sZPg94Mb4J6X4E/bp8CeEvHfhj4sab+yx8d9b+LfgTxB/wj/wDw kH/CP/ET4YfAb44aT4r8Jax+ytrH7Sfxf+Imjvrui+LfHvg3xd0Hiv8Aa8074gad8IfBP7J1 74f8a/GT9pDw/wDFTxB8Or7x/oPirRfBfwf8F/AvxV4M+H37Q3xN+O/grU5fAnxEg8Qfs8fE T4i+Cvhd4p/ZT8/wN8ffEHx98Q6X8F/GR+BHhvQvjr8c/gB/mS/s6/Cr9tPxX/wVM+O/wA8K /BzwH+0Snwx/b/8AiT8IPjD8Vf2k4/A/xe8HfCXxl8Zv2j9J+FuseI/id+2b8Z/2ddQ8BeOv GfxN074VeJvht8EL/wDag/Zp+JOjeIviR498a+NP2a/2Lb39q3x1oGiJ/Vl/wTb/AGbv2K7r /gqZ/wAFD/g9+2D8Ev8AgnLp3xc+KHw7/Ydvvgx+yDc/Db4T2lr4J+Ifwh+H/wC0p8Iv2s1/ Z3+AHxQ0JvE3hvwZ8TfF3wEuf2tfCQ8KaZqGueNP2S/i7+zh8efiU+man4+k03RpUlJySveL s001rvpdK6fSSvF9G7M1qUalJU5TUeWrBVKcozhUTi9LN05SUZxek6cuWpB2U4RbR+9Df8E9 dR+JfxC+HHxP/az/AGv/ANp/9pK5+G3iDw/8SfD3wM0/xH4V/Z0/ZH8PfGXwz8TPhj8ZPCnj bSvg9+z54Y8C/ET4keH/AIW/ET4V+H7r4KeBv2u/jt+1bB4G0SS6XxDrnj/xtd6j4+1D9H6+ If8Ah2X/AME3f+kfX7EP/iKHwH/+YKj/AIdl/wDBN3/pH1+xD/4ih8B//mCqjI+3q8A8R/Av /hIP2p/g3+0v/wAJT9k/4VJ+z/8AtLfAv/hCv7E+0f8ACQf8NEfEX9k7x/8A8JT/AMJH/a8P 9lf8If8A8Mv/ANk/2J/YOpf8JB/wnH2/+19E/wCEZ+x+IPIP+HZf/BN3/pH1+xD/AOIofAf/ AOYKj/h2X/wTd/6R9fsQ/wDiKHwH/wDmCoA9f/ZO+Bf/AAy/+yx+zT+zR/wlP/Ccf8M7/s// AAb+Bf8Awmv9if8ACM/8Jh/wqT4deHPAH/CU/wDCOf2v4g/4R/8A4SD/AIR/+1v7E/t7W/7K +1/YP7X1L7P9sm+X9O/4Jh/s8XmnftveEfH9v4g8VfDb9tvxA1r4t8H+GfG/xb+FGo6D8GtU 8VeOPjh4z+Clz47+HnxR0jxj4i8P+PP2sf2g/wBsj46+LNVttT8MT674V/af1n9nDW9P1T4E /DzwP4Ss/Qf+HZf/AATd/wCkfX7EP/iKHwH/APmCo/4dl/8ABN3/AKR9fsQ/+IofAf8A+YKg BP2QP2G/Bf7HXjT9q3xV4O+Ifxg8c237Tnxg8E/E5dO+Lfxq+Pvxo1HwRp3gn4BfCb4M2vh+ TxP8dvjF8WdX8V+INQ1f4feIfFWpfEeU6F4q1Lwrr/gP4Raw2q+CfgX8ME0r7fr4h/4dl/8A BN3/AKR9fsQ/+IofAf8A+YKj/h2X/wAE3f8ApH1+xD/4ih8B/wD5gqAPPp/2L/2h4Pjf+1D4 18C/tv8AiD4F/Cn9pT4weEfj3caD8FP2fvhJcfH3w58QvC/7NX7P37Mk3hzUPjL+0YP2kPg3 4h+D+teG/gRZ+Mrrwxpf7J3g34mWvjTUtK+w/GeHwtouueGfGh+yf8Sf2uPhx8ZdW/Y3/bl8 bfB/4x+Nv+FP6P8AFv8AZp/ad+E/gbW/hLqP7S/w9+HEHw7+HX7S0nxh+Bf9ufEDwt8H/jB8 H/it8QPhbret6l4U8f2fwz+LvhX9ofwbc/CTwF4Sufhr8WPCvhH0H/h2X/wTd/6R9fsQ/wDi KHwH/wDmCr5g+Pn/AAS3/ZB8OeKvh78c/gr/AME0f2QfjBq/w/8AD/xB8EeMfgAfBHwA+D/h Xxp8PfiBqPw88X+IfHfhfw5rHwC8TeCfih+0/wCCLn4PaV4K/Z40D4nfEH4AfDODTvjB8XLH xp8cvh/pHiCXW7UA+/vg3on9lfEX9rG//wCF6f8AC2/+Em/aA8Oa3/wgH9r/ANpf8Mv/AGf9 lj9mnw5/wov7H/wlPiD/AIR//hIP+Ef/AOGl/wCyP7J8D+d/w0R/b3/CLXf9t/8ACa+MPl// AIKAfHf4++H9R+AX7IP7HeqeH/Cn7WP7ZfiDx/o/hz4v+MvAHjT4ieC/2WPgF8JvCttr/wAf /wBrDW/DWieFtU8EeKvEHw8ufE/wt+F/we+HfxR8X/D7wX46+Pvxx+E9n4i1bV/B2n+L9Cvf kH9kn4Kf8Eivjr8Xf2lPg7L/AMEt/hB+z5+0b8O/iBp958TvgX+0r+zj+zJr2sTeX8E/2edb bxH8EdX+HHiz49/AW/8Ah/oPgX4nfA+6+JPgr4E/EKP/AIVl47+J+g+MPjL4A8G+M/2g/D/i n4pdB+zh/wAE9/2B/iH+1V/wUP1jxD+w/wDsgtpHwc+MHwI/ZW8C+Arf9mr4MN8PdL8K+E/2 Ufg5+1befEWHwtfeCr22svjB468bftqeMfB3xC8XaPLpeneJ/hn8I/gD4el8O22r+AtU8R+K gD9ffh18OtH+HOjz21tP/wAJB4t8Qf8ACO6n8Tvidqfh3wJ4f8d/Gjx34f8AAnhH4cN8Uvik 3w48I+BPCWsfEDWPCXgTwno2oaho3hPw/o9jo/h/QvDPhnQvD/hLw/4f8P6V6BX4h/Cq1/bE /YW/aRt/+Cf/AOz/AOBfA/7Rf7Lvib4IeKv2gP2SNc/aX/aI8T/CnXv2efBnww8eeBvh38Wf 2SIPH3hj4Q/tN/EP4v8Agf4Y3nxd+DfiH4Eaz8Q/A3g7VfB3w28X3vwsuPiN8TYvh5pTaH7X 8av+Cg3xc/Yri0D4jft+fs3eDPhN+y1qcet6X4r/AGlP2afjL8V/2ttG+C3jGNdMfwJYfGv4 ar+yV8FfiVoHgz4o3U2qeEPCvxB8BaF8TNP074ljwj4L8XaX4cXx9oGtEA9y/wCCivgn9tD4 ofsj/Fj4UfsE658H/BP7QfxW8P6r8ONO+Kfxk+JPxW+GGnfB7wr4v0TV9J8T/E7wDrXwZ8De NPG118YPDltPBH8L1guPCGneGfFV/ZfETUPEGrR+CU+H3jf8If8Ag1n/AGGf24v2DvhF+014 C+NfjL9n/wAa/sy+Mf2gPjdp/giy+HXjHxbdeO/Av7R37M3xs8c/shfHLU59B1/4B+E/+Ei+ H/xi/wCFJ6VqXh3XdQ+LYuvCej/DXwjJa/C2w1r4n+O5fC/6vfDH9r7/AIKXfHjUfEHiH4d/ 8Er/AA/8E/g3J4f+HHib4X+I/wBvL9tjSfgD8ZfiLp3jjwqut61ba18AP2dv2c/21tX+D3iD wHq6SaP4h8J/Fbxj4a8VRQajoMtxo1j4kPjLwh4G8A/4J8+Pv+Cklr8BvH0Xg79lD9iDXdIb 9t//AIKbXN5feJv+Cg3x58J6jB4qvP8AgpJ+1feeOtGttL0v/gmT40trrw/4c8bT+IfD3hPx NLrFnqPjTwrpejeMdY8J+AtX12+8C+HAD6//AGvPgD8ZfA2o3v7YP/BPb4e/B8ftfaX4g0HX vjh8OfEEMHw807/goV8GvDXhWXwve/s+/E34ladcWekaD8YNB0iz8Oap+yn+0T8S9C8cT/A/ xV4VPww+2eGPgD8bPj5Ya/8AX/7PXxr8K/tKfAL4H/tGeBdP8QaT4J+P3wf+Gnxr8HaX4std OsfFWm+Ffip4L0Xx14e0/wATWOj6rr2kWfiCz0jXbO31m10vXNZ0631GO5hsdV1G2SK8m/hj /wCDYz/goX/wXm/aX8d6J4K1nTP+Gwf2BfCPxAtPBXxr/aF/ai8VTad47+DP9oaP8QfHmq2X w1+O91Pf/E344/ECW98ReGbzVfAHizw58d/+Ee0dfhH4AufEf7Mnw68c6f8AEjT/AOp39hT4 j+KvDn7bX/BVP9ie6+GPiDwX8KfgP8YPgr+1B8BPFWstqMWneNPCv/BQTwP4o+LvxuTwmNX8 Pwaj4j8P2v7aHgv9qXxhc+NH8aeMNOg8VfETxN8HfDdj4G8LfBbQ/CtqAfq/RRRQB8Af8FYv +UWX/BSz/swD9sj/ANZ1+I1H/BJ3/lFl/wAE0/8AswD9jf8A9Z1+HNH/AAVi/wCUWX/BSz/s wD9sj/1nX4jUf8Enf+UWX/BNP/swD9jf/wBZ1+HNAH3/AEUUUAFFFFABX4A/8FD/APlOv/wb q/8AeXL/ANY88E1+/wBX4A/8FD/+U6//AAbq/wDeXL/1jzwTQB+/1FFFABRRRQAUUUUAfgD/ AMEC/wDnNR/2n+/4KN/+8br9/q/AH/ggX/zmo/7T/f8ABRv/AN43X7/UAFeAfs063/wkHw68 R3//AAov/hnf7P8AtAftY6J/wgH9kf2J/wAJB/wjP7U/xk8Of8L0+x/8It4P87/hqD+yv+Gl /wC1/wCybv8A4SD/AIW3/b3/AAlPjj+0v+E18Qe/14/8D9G+Mug+C9asfjt4s8P+NPG0/wAY P2hdZ0PWPDNtBa6dZ/BrxH8ffiX4h/Zz8J3MVv4Z8Jxt4g8Bfs+ap8MPAviy5bS7qe88VeHN ZvLrxN40uZ5vGOugHsFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBz/izwn4V8e+FfE3gXx14Z8P+NPBPjTw/rPh Pxj4O8WaNp3iPwr4s8K+I9OudH8Q+GfE3h7WLa80jXvD+u6ReXml6zo2qWd1p2qaddXNjfW0 9tPLE3xB/wAOv/2LNI/0b4W/Dr4gfsyeH3/f3ngL9in9pL9p39hf4WavrDfu7jxdr/wk/Y6+ MfwO+GXiL4gX9lFp+jar8Rdd8J6j471fw5oHhXwzqfiK78P+EfDGm6R9/wBFAHwB/wAMz/tp +Cf+Jr8Lf+ClHxA+IHiC4/4l95o37a37Mf7MXxg+Flto8v8ApNxqegeGf2OvBH/BO34m2PxA hvbTT7XStd1341+KPAlt4cvfFen6n8Ldb8Qan4Y8WeCT/hM/+Cmvw7/0TxF8CP2QP2m/D/hz /iYa78RPhP8AHn4n/sz/ABT+Imjr/wATbU9M+Gn7J/xS+EHxx+GXh34gWFlLP4O8G6F8Rf8A godp3gT4ieI9L03xV4u+KXwK8P8Ai7UNH+Hf3/RQB8Af8PB/DnhX/iX/AB0/ZO/b/wDgR4tm /wBM07wj/wAMefFP9rL+0fDkn7i08R/8LF/4J0WX7aPwS0X7Zqdvq+mf8IV4p+KWgfFPTv7H /t3W/AGl+EvEfgfxF4q9g+Cn7bv7F/7SnirUPAv7Of7Xf7MHx+8baT4fuvFmqeDvgp8ffhT8 VPFWm+FbHUdK0e+8Tah4e8C+LNe1ez8P2er67oel3Ws3FnHp1vqOs6VYzXKXOo2cU30/Xj/x r/Z6+AX7SnhXT/Av7RnwO+D/AMfvBOk+ILXxZpfg741/DTwX8VPCum+KrHTtV0ex8Taf4e8d aLr2kWfiCz0jXdc0u11m3s49Rt9O1nVbGG5S21G8imAPYK+AP2N/+Tiv+CsX/Z//AMOP/XWX /BNOj/h1/wDsWaR/o3wt+HXxA/Zk8Pv+/vPAX7FP7SX7Tv7C/wALNX1hv3dx4u1/4SfsdfGP 4HfDLxF8QL+yi0/RtV+Iuu+E9R8d6v4c0Dwr4Z1PxFd+H/CPhjTdI/MD4wfs2eLf2D/+Cgnw F+Ivwy/bT/aA+F/hL/goh9r/AGX/ABb8SfiroX7DvxL8CXX7Tv7P/hibxz/wTb+B/wC0Frnj /wCF3w9/at+Ofw/8Z/C1P2rPgnrXj8fHTxN+2n8a9Y0n4AfC7xB+1j4b8W3fgzxtGAft/wDG 39qr9nH9nDWPhR4Z+OXxo+H/AMNfFvx3+IHhX4W/BTwT4i1+1j8d/Fnx34x8d+BvhtpWhfDr wNam68W+MfsHi34leCLbxdqegaNf6P4A0fX4PFnjvUPDnhK11DXLT4A/4K4/Av8A4ajuv+CZ n7N+s+Kf7G+GXxS/4Kf/AAl1v41+ENT0T/hL/Anxr+Fn7Ov7OP7Vf7XOq/Av4peArrV9J8P+ Ofh/8S/EH7PnhnR9Q0jxZHrvhzRtYXQvG9z4W8SXvhPT9Iuv5wf2q/8Ag2X/AOCmuv8A7X/7 Of7b2oft+f8ADyz4geDP2gPhj4u+J2h/GDxZ8T/2IPHfhzwJpn7QHhPxs3h34C/En4ceMPjZ /wAKd+H/AId/4Sz4o+OLuD4Pt8LdY+BGj6TNqP7N/wAOviF8QNT8P+Bo/v8A/aW/Z3+JPw/+ NH/BPbQ/il+yD+3/AOJPEGs/tf8AjWSzm/Zc/wCC5P7WP7RXg7xRo7fsC/tw3Fv4I8DfEL9s X9sH9h74m/Cf9oDT73RtQ8c+JtY0L4beEPAkvwJ0LxD4J0z9pDxZ4g+KPif4A6mAfq94s+Bf x9/YMg8TfEr9jj4o/B/Uv2XF8Qaz8QvjN+y9+3b8bPGnwx+AX7MXwk8HfBq50pLj9jD9ofwx 8Ovitq/7J3wf8Hav4W0LxR4v+APxD+HPxe/Z48OeC4tUsPgDD+yhoeh6jpnjT85f+CKvxB/a g+FP7O3xo+O+uf8ABN/9rvxen/BSz9sP42f8FNtCHwz+I/8AwTy1L4f+APAX7X1v4L8SfDnw ho/iv4j/ALdnwr+I/jqOz+H2i+GvE2reIvE3wS+EmvQat4j1HwvL8PLd/Dker65ynxl8efsC 6h8SfDnwU0qH9pCy8A3XgfWPHn7QXxY/4LOa9/wW48a/sJ/ATSpNe0vSvgPD8e/2YP2/fFHw +/Zo+LP/AA0B4x0b4kaD8Cde+Nnxa+Dngzwb8YvhHb+IvAnijxl8dtC+GHwu8Xfo3+zv8W/+ Cjvxx8XfFvwhd/tN/wDBOWxl8IR/Dz4nfCXxL8Mv2S/jt8ZPA3xy/ZK+Omkazffs/ftI6D4y 07/goF4V0DSY/iTrPgX4ueE774fWd54ouvDup/DG98Q2HifxV8O/Gnw48b+LQD4J+Jn/AAUx /ZwOp/A7wv8AtIa38Bf2JPhYvx6vP2lrf9gyy0jx9cftmfGz4r6R47uf2gPhJon7W2meL/h7 +y98Lv8AgmT8QrT9qPXPhP8AtReMPEPxR+IHxN+Dv7THjP7frMv7Us/7MVv8SfiZ8a/y8+Pv 7X37CEv/AAUF/Zi8VeL/AILfsw/tWftdftK/s7/HD4ifGX403v7Sn7OXww+BP7Nnxk+PPxs/ ZgT4AeFPEn/BRz4e+J/G978EPiB/wTI/ZV/Ze+KvgHwV8Y/gD4WsPjD4h8Yz+APih8BvDK/G z9rHxvrOm/1yf8IF/wAFIv8Ao679iH/xX18eP/pmlfiD/wAE5vjx+2f+2J/wUd/4KmfEL4R/ tbfsw+NPh/4V+H/7Cvw0+Fvx0v8A9h/4raj8CfjP8LPA+qftk6JqGpfs0aRpn7Xfw11q/wDh /wCDv2mrX9qLwfr3xY1T4xftJeHPiz4x07Vrr4a+MvCvw/8ADOheFopUVFyercndtu7stFFd FGK2iklduTvOUpS2qVp1IUqbUYU6MeWEIR5Y80rOpVnq5TrVZJOpUnKUuWNOjDkoUaFKn+n/ AOyr+2p+wx+z/wDs4/Bf4KfE7/gr/wDsw/tQfED4ZfD/AEDwj4s+P3xS/ak/ZusvHfxQ1jSr UQ3PiLXbfRvHH+7p+mT+INV8YeO7vR7LT7r4j/EX4m/ECbxN8QvE3v8A/wAPNP8Agm7/ANJB f2If/Er/AID/APze0f8ACBf8FIv+jrv2If8AxX18eP8A6ZpR/wAIF/wUi/6Ou/Yh/wDFfXx4 /wDpmlUYh/w80/4Ju/8ASQX9iH/xK/4D/wDze0f8PNP+Cbv/AEkF/Yh/8Sv+A/8A83tH/CBf 8FIv+jrv2If/ABX18eP/AKZpR/wgX/BSL/o679iH/wAV9fHj/wCmaUAH/DzT/gm7/wBJBf2I f/Er/gP/APN7R/w80/4Ju/8ASQX9iH/xK/4D/wDze0f8IF/wUi/6Ou/Yh/8AFfXx4/8ApmlH /CBf8FIv+jrv2If/ABX18eP/AKZpQAf8PNP+Cbv/AEkF/Yh/8Sv+A/8A83tH/DzT/gm7/wBJ Bf2If/Er/gP/APN7R/wgX/BSL/o679iH/wAV9fHj/wCmaUf8IF/wUi/6Ou/Yh/8AFfXx4/8A pmlAB/w80/4Ju/8ASQX9iH/xK/4D/wDze0f8PNP+Cbv/AEkF/Yh/8Sv+A/8A83tH/CBf8FIv +jrv2If/ABX18eP/AKZpR/wgX/BSL/o679iH/wAV9fHj/wCmaUAfEHxM/a2/4J3ftg+H/wBp v4QftQ/th/sA+HPBPhz4wWZ/Yu+Lvgz9qn9l2f4y+ANOn/Zf+Fo0z9qz4V+Ktc+IvxAk+D/7 T/wf/aD+IH7Q2hfCH4m6Z4a8F+KvBUHgvwpr+leH7q2ul8VeM/H/APgkP/wUt/ZJ0j9kTX/C f7S/7a/7EPgz9o3wv+1/+33P8btP0X406J8P/hZq/jv4kftsfHj41v4u/Z/uvjLreg+IPiJ+ z/4y8P8AxP0HxN8KfiLpNz4l0fV/DmpxaNf+IpfGfh/xbpWkfQHjPxd+0p+yX4O/bH/aN+MX /BUv9iGy+GXgT4gaV44+Olz4/wD2PPjd4t8Ofs1axb/An4D+GdI+Dngrwnon/BSm58QeCP8A hN/D9t8Pvir4c+C1rYa347+IfxT/AGgL3xJ4P0rWL34weFtGn+AP2Qvgr+3j+yD471v9lzxB +1j+zD+zB8ev+CwP/DUv/BSaL+2v2aG+LXjv4N/tk+JtH+D3/DXn7PPwq+2/tn6P8MvFv/DP 9l47+HHjn4Aamvh79oex+KOj+B/2gvE3xO8O+H/Avwy0H/haIB75af8ABQiz+Pn/AAUW8IeJ f2dvH/7Gnj4aRofxq/Y7/Y3+EHj344fFb4Z/ET9re28X6N4R+P8A+1N+1n4W8S+Ev2f/AI2R r+zZ8K/Ff7FWo/s6/Cfxlonw21r4QfFT4j+AvjzfR/tHWOtWnwr+GfjXtP2vvg58df8AgoV8 ff2XP2Bf22PBvww+C37Nfibw/wDGX9sn4leEv2bP2k/jD8WNa/aPsv2SvGn7Ofgjw/8AAn4i eJNa+Cn7LNt4B+GF542/aj8K/ErXEtPDXxX1/wARax8NvD954O1j4LeNvCnhrx834OeJP+De T9s39iP9vH4U/wDBQ7xH8Xv2lP8AgrJ4I8Lx6ndftE6z8Of2g/i3+zh/wUIm0m5+EHxI+HWs a94H17SfivF8R/iJZ/Dr4fWPg2z8IeGfh5+09YfFL4vaxc6T8AYfhxp3w2vdc8XwfovfeIv+ CP8A4v8A21v2SPGnhr/got49b4PeIf2JP2y9a13xn4n/AOC0n7cPh3xJ4S8WeIviz/wTu1X4 XeCfEPijxz+2dpXxP+DeueMPC/8Aws7VdW+Cesah4LvPGd/8PbjUfHPgfV/EPwU0efwUAfq3 +1V+zF/wSK/Y3/Zx+NH7Ufxr/YQ/Yh0j4ZfA74f6/wCP/E3kfsv/ALMlhrGu/wBkWp/sbwV4 R/4SzQPC/h/U/iB8QPEEuleBvh14c1DxDpH/AAlfjvxF4d8M2t7Fe6vbZ5/9jb/glN+yD4a/ Z48HTftB/sB/sgx/GTx34g+Kfxp8deD/ABN+z78APH2o/BjUfj98W/HXxws/2bLbx3Y+G9c0 jxv4f/Zc0j4g6d+zn4T8YeHrjTvCvifwr8L9G1zwp4Y8HeG77S/CWifP9r4N/wCDfh/jL8FP j/4x/bJ+APxq+K37OPiDVfFnwJ8Q/tM/8Fbfid+1Tp3wr8VazBp8V74m8HeDv2kf2ufip4J0 nxAlzo3h7W9O1mLw4dR0bxV4V8H+L9HubDxT4P8ADOsaT+j/APw80/4Ju/8ASQX9iH/xK/4D /wDze0AH/Dsv/gm7/wBI+v2If/EUPgP/APMFX4g/H/8AYj8L+L/24v2vfhb/AME0/wBkX/gj F4o+Jvwf/Z//AOCbf/Cwvh1+2L8A9O1v4J/C7/hYHi3/AIKd+IviD9j8I/APwnc+IPBP7QHj bw/bfsu67cf23p+mf8JJ8Irfwxqet/bbKL4eTr+33/DzT/gm7/0kF/Yh/wDEr/gP/wDN7X5g f8E7f23P+CXWr+O/22P+CgNz+11+zD8L/ib+3z+0An2/wz8Uvj54a+GnjvSPgT+xzo8v7Jf7 OX9u/Dz4q+LPBviDQf8AhZ/h/wCHfiz9qbTP7Z+Ffw+8Y6Ro/wC0lp/w28Tf8JlZfDfw34x1 cA+QP+HZf/BXj/pH1/waR/8AiKH7Tn/zBUf8Oy/+CvH/AEj6/wCDSP8A8RQ/ac/+YKv3+/4e af8ABN3/AKSC/sQ/+JX/AAH/APm9o/4eaf8ABN3/AKSC/sQ/+JX/AAH/APm9oA/nB+LP/BIz /grx8V/hZ8S/hb/wxf8A8Gsfw1/4WV8P/GXgD/hYvwn/AGdP2nPB3xT8A/8ACY+HNS8O/wDC a/DTxd/wrXUf+EV+IHhX+0f7d8G+I/7Pv/7D8R2Gm6n9iuvsvkOfCf8A4JGf8FePhR8LPhp8 Lf8Ahi//AINY/iV/wrX4f+DfAH/Cxfiz+zp+054x+Kfj7/hDvDmm+Hf+E1+Jfi7/AIVrp3/C VfEDxV/Z39u+MvEf9n2H9ueI7/UtT+xWv2ryE/o+/wCHmn/BN3/pIL+xD/4lf8B//m9o/wCH mn/BN3/pIL+xD/4lf8B//m9oA/AH/h2X/wAFeP8ApH1/waR/+IoftOf/ADBUf8Oy/wDgrx/0 j6/4NI//ABFD9pz/AOYKv6wPDHifw3418N+HvGXg3xDofi3wh4t0PSfE/hTxX4Y1aw17w34m 8N69YW+q6F4h8Pa7pVxd6XrWh61pd3a6lpOrabdXNhqNhc295Z3E1vNHI25QB/CR8OvgN/wU r/aQ/ai/bI/Yw8D/ALBf/Btt8LvjD+wPrn7J3ifx78Vvhn8H/wBtH9nPXbPxJ8afDS/tAfB3 xD8APjv+z34h8J/HfwzrnhMeDbb/AISnVrK7+Gl/bakv9i2Fx4m8PahqUkv3P+zx8Tv+DmD4 d/Ea8/4J63/j7/gj54/+MX7PnwE+FvxMtviX+094x/an8S/Eb9ob4U+OPEfjnwlZ/EXw1qXw yuvD/ijxnZ/DHxB4OT4W/EvxP8Q/hR4H8Yw+I5PCeseKtV+IV74/034k+M/tL/gnh/ynX/4O Kv8AvEb/AOseeNq+6f2u9R0r4Z/tcf8ABM/40XnxH/4QH/hJPjf8af2NPENjrN94MsPBnjbw Z+0f+zv47+Luk+E7658T6NPq9r441f8AaG/ZJ/Z0074cSeEvEnh/VdY1W/1HwQ9n4k/4TG30 xAD4W/46mv8ArAD/AOdFK+QPjN+xT/wcj/HH9rH9i/8AbF8Wa/8A8EQdO+Jv7C//AA0X/wAK k0Lw7qv7eVp4E8Rf8NN/DbS/hb49/wCFi6ZqXhTV/EGr/wBkeH9Itrzwj/wjPifwj9g1h57j Wf7fsmj0+L+r2igD8Af+Opr/AKwA/wDnRSj/AI6mv+sAP/nRSv3+ooA/mh/aF+Nf/Bzj+zX8 Avjh+0Z460//AIIQ6t4J+APwf+Jfxr8Y6X4Ttf8AgoHfeKtS8K/CvwXrXjrxDp/hmx1jVdB0 i88QXmkaFeW+jWuqa5o2nXGoyW0N9qunWzy3kJ+z18a/+DnH9pT4BfA/9ozwLp//AAQh0nwT 8fvg/wDDT41+DtL8WWv/AAUDsfFWm+Ffip4L0Xx14e0/xNY6PquvaRZ+ILPSNds7fWbXS9c1 nTrfUY7mGx1XUbZIryb9X/8AgrF/yiy/4KWf9mAftkf+s6/Eaj/gk7/yiy/4Jp/9mAfsb/8A rOvw5oA+AP8Ajqa/6wA/+dFKP+Opr/rAD/50Ur9/qKAPyB/4I3fsU/tT/sXfCz9r7/hsXX/2 f9f+Nv7WX7f/AMf/ANtbXf8AhmjVfiLqnws0X/he/hz4X/2noGk/8LS8KeFfFunf2d4t8K+J /sGlXn/CR/Y/Dk2g/aPFesanJqH2f9fqKKACvmD9kTRvg1oPwp8WWPwJ8WeIPGngmf8Aaf8A 23dZ1zWPE1tPa6jZ/GXxH+2h8ffEP7RnhO2iuPDPhORvD/gL9oPVPif4F8J3K6XdQXnhXw5o 15a+JvGltPD4x136frwD9mnW/wDhIPh14jv/APhRf/DO/wBn/aA/ax0T/hAP7I/sT/hIP+EZ /an+Mnhz/hen2P8A4Rbwf53/AA1B/ZX/AA0v/a/9k3f/AAkH/C2/7e/4Snxx/aX/AAmviAA9 /ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACvAP2o/2b/An7W/wJ8c/AH4i6x8QPC/h/xn/w jOp6f42+E/jfWPhv8U/hz47+H/jHw98Sfhb8Uvhp450KRb3w38QPhd8TfCHhH4heDdQnt9T0 ceI/DWmw+ItC8QeH5dT0PUPf6KAPzg+BH7d+oz/H3S/2JP2vvhp4g/Z6/ax1bw/4/wDEHwg1 /WLPwrYfAL9uLwX8LfGninw14l+Jv7J+u6B8UPipc6T4gTwRo3hD42fET9lP4oeIrb4+/Arw X8T9JgvD8VvB3hTXfi/d/wA4P/Bc/wD4N5vFX7df/BWn9jT9oH4UaR4gsfg3+1f4g0T4cft7 eMfD8+oxT/C6D4G+Ef7Yg+Jy+IdQk+Jkfh3xB8Xf2fPBdx8Fvhisfwg0r4NeG/jL8MfhxafE TxA3iT49QS3P9b37S/7Kv7OP7ZHws1b4KftR/Bf4f/HH4Zav9vn/AOEZ8f6Ba6v/AGFrF/4c 17wn/wAJd4K1nEXiD4f/ABA0zw/4o8Q6f4c+IvgbVfDvjvwp/a97deGfEWkXsv2kfD8f7Cn7 bXwh8VeArr9lD/gqn8YNP+FPhnxB8W9Z8Q/AT9uv4K+B/wBu/wAK65p3xB1HUtX8HeE9K+N0 Xij9nP8AbQh8P/CfUfEOsv4bufiP+1L8WfFWpadpXw/8N6l4mHhbwprGh+MQD6Z8cfso3Wl6 /wDDbx7+yl468P8A7L/jT4T/AAoX4GeH/CGm/Cbwx4o/Zv8AGnwisL3QpPAvgD4t/BrwzqPw r8W6/wCH/gPaWXiib9my3+G/xm+EUnwc1n4g+PI7OXXfAfjv4hfDzxn88fCv9k//AIKG/DDx n8a/iJcftxfssfEnxx8cPHFt4m1jxP8AEX/gn38RbnVfB3gzQdKi0n4f/ArwBceEP+CgPg7+ x/gh8MPP8T654H8JasuvarB4z+IvxS8feIfEniHxx8SfGPiHWPTv+Fc/8FTf+jyP2AP/ABWn +0V/9Nirx/4Kf8E8P2h9W8K6h4a/4KQ/8FFPjB/wUL0ibxBdX9v8NdN+EXwk/Yw+AWs+H5NO 0qwh8N/Fv4c/s52Nj42+P3h/UbaTxzoHj34VfGX4v+Mf2X/ip4L8ax6F8RP2cvEOr+FtD8UI AfIP7R3hP/gqL+31/wALX/YY+HXx8/Zhtf2S/iV8P/jj8Dv2tP25/Af7IviXwd/wgniOw/s3 wT4x/Zt/Z68I/EP9tz43/wDC+fiBr/8Aavi74XfHfxxB4R8HfCz4C/YPiR4J8O/Gy6/a0+Gv ib4XfDr2D4j/APBMD9qXxX4q+GPxR+Ff7VH7IP7KHx2+CHwfb9nr4M/HP9l//gnt8RPAnir4 ffAKXUfD98/wOf4feJ/+CgPjn9nz4l/B/T4/D0MHgv4afGz4L/E7wX8JtRvr7xt8HNF+HvxJ XTvGun/s74T8J+FfAXhXwz4F8C+GfD/gvwT4L8P6N4T8HeDvCejad4c8K+E/CvhzTrbR/D3h nwz4e0e2s9I0Hw/oWkWdnpejaNpdna6dpenWttY2NtBbQRRL0FAH4heLP+Ikaz8VeJrPwKP+ CIXiPwTa+INZtvB3iHxYf28fBfirXfCsGo3MXh7WfE3g7R18e6R4T8QappC2d9rPhnS/HXjT TtC1Ge50ux8WeI7a1i1i88/+Afxz/wCC7XjT9tD4hfsj/Hu0/wCCYPwz0j4dfswfD79o3Wvj f8FPhp+0p8ePCtrqPxd+K3xD+Gfws+FWoeEPiD+0l+zN42TxB4qtvgn8bfF114k0PTPEXhXw 5p3gbStM1e/i1fxppNvB+/tflB+0x8SdO/YR/bQ0z9tv40eNvD/h79jz9pT4P/Ab9if4xeKL zwN4quJ/2cfjL8NPit8evHv7Nnxm+JnxNsdck8E+AP2YPiTc/tF/FH4J/FLxr428O6fB8O/j LqX7Mk8/iSHwH45+JGveAQD6B/4QL/gpF/0dd+xD/wCK+vjx/wDTNKP+EC/4KRf9HXfsQ/8A ivr48f8A0zSvt6uf8WeLPCvgLwr4m8deOvE3h/wX4J8F+H9Z8WeMfGPizWdO8OeFfCfhXw5p 1zrHiHxN4m8Q6xc2ekaD4f0LSLO81TWdZ1S8tdO0vTrW5vr65gtoJZVAPkH/AIQL/gpF/wBH XfsQ/wDivr48f/TNKP8AhAv+CkX/AEdd+xD/AOK+vjx/9M0r5+/ZD/4KpeFf2pvjLZeCte+D 3iD9nr4U/tB+H9e8c/8ABNL4n/GTxZp3h3xp/wAFEfhn8LYIm+PHxJ8A/Am/0bTfG3wh8P8A g621zwF8QfhfofxNvrb4hfHX4BePLL45+F/BOkeFvCnxCtfCP6f+LPFnhXwF4V8TeOvHXibw /wCC/BPgvw/rPizxj4x8Wazp3hzwr4T8K+HNOudY8Q+JvE3iHWLmz0jQfD+haRZ3mqazrOqX lrp2l6da3N9fXMFtBLKoB8g/8IF/wUi/6Ou/Yh/8V9fHj/6ZpR/wgX/BSL/o679iH/xX18eP /pmlefeE/wBrD9rj4xeFfDXx9/Z5/ZG+D/xP/ZP8feH9G+JPws8R6/8Atda38Nv2oPi38GtW 0621vRfG3gj4Aat+y7q3wb0bxB8VPDbr4s+Bvgb4vftefCmfUvD/AIj8CW37Q2ufsx+Mb/4g +EPhh0H/AA8h+BPg7/RP2l/B37QH7F2p6d/yOuqftR/BLxj4V+BPw1+2fvPDn/Cc/txeALf4 lf8ABPiw/wCExt7rQbfwz/ZP7WWtfavGPirw98Ib/wDs7423F78NbAA6H/hAv+CkX/R137EP /ivr48f/AEzSviD9rv4/f8FTPgH4q+BHwQ+CHjj9kH9pb9qP9pbxBrsPww+GEP7C/wC0T8Nv hn4W+Gfw21HwQvx2+P3x++Oy/t+/EDSPg/8AB/4P6R8QPCFvcXFv4Q8b/EL4h/ELxv8AD34Z /DP4e+Kdc8U3V1oP094s/wCClPwz8S+FfEx/Yu+Gvxg/b0+JM/h/Wbn4M2XwI+G/xCtf2YPj P4q03Trm5fRtL/4KJ+J/Bdn+wfoXh/Qr+z1PSfH/AImb48a1qPhjxB4c8U/DbQ/CfjT47aZp 3wd1v0D9kT4KfH3w14q+O/7RP7XWofB+8/aR+PPiDQvDFr4e+BF1401X4Z/Bj9mD4Oaj43l/ Z3+Aml+MfGmleC9X+LviDw7q/wATPjD8XfH/AMZ9a+Fnw18QeJ/iF8cvFPgyz8OWPwu+HHwq 0fRAD8ofgF+wl+0b49/aq/bd+Ini79sX4A/tD+Nvhn+2/wCE/Gd/4S/aW/4JxXWsfBr4M/tK /wDDKP7InxD8FfFT9mnwZ8Pv28PCcb+IPAX7Pmqfs4fCjwD8XvjBH4t+N/wxn+HXj63+HXiv QLn4tfHPxx8ePsD9qn9hj9vj9q3wr8OtJ1b9vP4A/Brxt8GvjB4R+O/wZ+M3wI/Yo+M/hL4m fDL4meEtO8ReGH1TS08T/wDBRLxt8O/F/h/xf8O/G3xB+Fnj/wAAfFP4feP/AIe+M/h74/8A FOi614WuLm407UdM/R34aaz8ZdU8aftC2PxP8J+H/Dngnw58YNF0b9nPWNGuYJ9R8e/Bqf4B fA/xDrnizxZFD4m12Sz8QWf7QevfHbwLbW11pfgudvCvgvwzeL4Zura6t/GPiz2CgD+e/wAH 67+0Z/wUF+IHxH/4J4/txftDeDPgF41+F0fhLxp+1Z+yR8Ff2dPHXwM8Y/tZfs46zpMmnvrv 7Pn7VGsftkfGe6+JX7BnxN+JV3/wrv4kfEDwB8NPhL8fJ9P8N6t8FPjT4T/Zm8SfES58J334 7/E3/g2U8N6p/wAHCvw2+Jfhb4RaHpH/AATJ8VaHL+2V438Kaf4XsF+FWj/FL4ZazoGleJf2 TIdC1uz+K/hnU9D+KXxZ1jwL8WNT+HvjDw58Jfh/4g/Z68a/Gz4WfBGG1/4UhLHZ/wBfP7TP 7F/7MH7YeneDrP8AaJ+EHh/x7q/w08Qad4s+FPxBtb3xB4G+Mvwb8VaX4q8H+NbfxN8FPjl8 O9Y8JfGT4NeILjxJ4A8G32q6z8L/AB14T1HXIPD2n6XrVzqGkLJYyeP/APDJf7THgT/Tvgj/ AMFGP2gP+JF/ofgD4W/tR/DT9nv9pP4E6P4c/wCQZZeHPHOoeHPhr8BP22vix/wjHhqV4vDP jXxb+3T/AMLT1jxjpfh7xn8ZfH/xi/4rXQvHYB9/0V8Af8K5/wCCpv8A0eR+wB/4rT/aK/8A psVc/wCJv+CaXw9+NWnW3h79tD9oD9p/9u3wTpfiDwn4m0T4XfH7xf8ADP4efBoaj4R8VaN4 2trb4hfBf9jf4R/srfCn9o7w/f8Ainwr4M1ibwn+1X4O+OvhXRp/CsEXg7RvDFt4m8fweMAD 5A+J3xO1H/gs3qPh/wDZ3/Z38P8Axgh/4JhQ/GD4j+HP20f20fDnxH8K/Cj4e/tkfD34UeFW 0PU/2Tf2TdT0NvEvxx+LHwf+LHxx8S2vgv4//H/wXbfA/wCGeu/DP4H/ABu+FXwq+N3xBX4g sy/t94T8J+FfAXhXwz4F8C+GfD/gvwT4L8P6N4T8HeDvCejad4c8K+E/CvhzTrbR/D3hnwz4 e0e2s9I0Hw/oWkWdnpejaNpdna6dpenWttY2NtBbQRRKeE/CfhXwF4V8M+BfAvhnw/4L8E+C /D+jeE/B3g7wno2neHPCvhPwr4c0620fw94Z8M+HtHtrPSNB8P6FpFnZ6Xo2jaXZ2unaXp1r bWNjbQW0EUS9BQAUUUUAFFFFAHx74n/Y98N6T4k8Q/Ev9mjxjrn7KvxX8S65q3jDxXc/Dmws NS+CXxd8Y6zf3Gv67rPx9/Zw1Vo/hp4+1zx94kj0GT4qfGfwVB8KP2vvFPhLw7Y+BPDn7Ufg XQJJEHqfwM+Mv/C3NK8aadrnhz/hB/in8H/HB+FXxu8AQ6x/wlOleDfiTF4M8GfEWC38L+OI tL0Wz8d+B/Ffw8+IvgH4j+A/FS6N4c1668GeNtBsfiJ4G+GHxT07x18LfBXt9fEPw0/4lf8A wUN/a/0LTP8AiXaHq/7LH7CfxN1bRrH/AETStU+JPiP4i/t2/DjxD8QdR0638uzvfHGu/Dz4 OfCLwHrPiy5hl17VPBnwr+HHhe+v59D8D+GLHSwD83/+CeH/ACnX/wCDir/vEb/6x542r9IP +Cgv/JB/AX/Z73/BMv8A9eRfsoV+b/8AwTw/5Tr/APBxV/3iN/8AWPPG1fpB/wAFBf8Akg/g L/s97/gmX/68i/ZQoA+3qKKKACiiigD4A/4Kxf8AKLL/AIKWf9mAftkf+s6/Eaj/AIJO/wDK LL/gmn/2YB+xv/6zr8OaP+CsX/KLL/gpZ/2YB+2R/wCs6/Eaj/gk7/yiy/4Jp/8AZgH7G/8A 6zr8OaAPv+iiigAooooAK8f+B+jfGXQfBetWPx28WeH/ABp42n+MH7Qus6HrHhm2gtdOs/g1 4j+PvxL8Q/s5+E7mK38M+E428QeAv2fNU+GHgXxZctpd1PeeKvDms3l14m8aXM83jHXfYK+Y P2RNG+DWg/CnxZY/AnxZ4g8aeCZ/2n/23dZ1zWPE1tPa6jZ/GXxH+2h8ffEP7RnhO2iuPDPh ORvD/gL9oPVPif4F8J3K6XdQXnhXw5o15a+JvGltPD4x10A+n6KKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAr4A/4KEftoeMf2LvB3wH1fwB8E/+F7+Lfjv+0AnwL0nwt9u+O0f9i+X8Cfjr 8dL/AMU/2J+zR+y7+2J8bfFn2bTPgfeaJ/Yngr4F6/8AY/7e/wCEp8Sav4c8JeHNe1e3+/68 A/aE/Zi+EX7UGj+A9G+Ldp8QP+LX/EBfil8PfEHwt+Nnxs/Z/wDHfg/x3/wgnjv4Yza7oXxH +APxC+GXxAsvtvw/+JvjzwnqemR+Jv7H1XR/E2oW2pafd/6O0IB+cHhT/gsh4V1jxB8O9P1z 9mn4waV4W8e/B/4n6xoXxAtbnTtL074mftP/AAs/ag/ZM/Yl1/8AZP8Agp8Ofi/Z/Bn4/af4 gt/2vv2oV/Z+1X4ifto/B39h7w/oHirwnp/ivU9JX4U+IPEvxC+HXr/7GH/BW39lj9t342fE 39mjwDbfED4eftG/Bf8A4W1Z/Fb4I/FKH4df8J34D8R/Ab4u23wa+MHhzXU+FvxJ+KXh9f8A hEPEHiT4X6tpnjWy168+FnxO0f4p6fYfBvx/8RfGfwp/aS8JfA8+IX/BK39n+Xw54wvvglpv /CIfGDWfh/dfDvwj4y+OnxH/AGv/ANor4dfD+18SfFP4O/GH4i/EDwt8J4P2u/hJe+EP2gPH 3xN+CPgb4363+098KPiN8Lf2jtT/AGp9C0j9qbxV8VPFnxgXxFrfij0D9h3/AIJ3/CL9h/w5 HJ4P174geJPib4k/4WVr3xi8ZXnxR+NjeDvix8SfjJ8U9U+MPxB+JPiT4T+MPiz8QPD/AIo+ IEXiDU7XwF4K+N3xi1L4yftY6f8AAnwh4A+EnxC/aV+KNl4butb1kA+QPiR/wWVtfhJ+3t8X v2UvHvwH/sr4JfAT/hZ/iD4vftG6fq37R3ifWPA/wi+C/wCwf8P/ANtb4qfHXU/A/hT9jbW/ glcfD/wPqfxb+EnwE13w1pv7WV98bLfx38WPhbq0fwkl0z4jeDLXW/X77/grl8JNL+N/wQ/Z c1L9nj9p+y/aj+OHiD9qbwNY/AGSx/Z4m8VeAviZ+yx+zV8Of2t9U+G3j3xzZ/tF3PwObxB8 XPgd8Y/hH4k+EmueA/ix46+Hqaj8QdN8OfFrxt8KNc8P+OrLwn9geLP2L/2YPHut+Jtf8dfC Dw/40ufGnxg1n47+MdN8WXviDxH4V8WfEzxH+yPc/sI+IdU8TeCdY1i88Ha94f139k68vPhB rPgDVNCuvh7qmnXVz4lvvC0/jeeXxM3P+D/2Cv2TvBHiP4O+OdM+FP8AbXxN+A3xA+IXxS+G /wAZfiF46+JPxW+O1t47+Kvwsuvgf8QNd8YfHb4n+MfF/wAYPil/wknwfbQvhtdaZ8UvG3jL R7bwd8PPg7oen6fZ2XwS+EMXgkA+AP2e/wDgvB+yx8Zvgn488f8Ainwb8QPhr8YPg3+wA3/B Qv4x/s4war8OvH3jvQvhZpfwi8CfHHxDpnhHUtC8ZWVlrf2j4ZfGD4EeNfh14q8f2Xwm8OfE rR/jf4d8OaXPpvxg+EX7W3wo/Zr/AGe8J6zqPiPwr4Z8Q6x4T8QeAtX17w/o2s6p4F8WXPhW 88VeC9R1TTra+vvCfia88C+JvGngm68QeHLmeXR9ZufB3jHxZ4Vn1GzuZfD3ibXdIaz1S6+I PAH/AAS//Ys+GHws8a/A/wAFfDr4gaZ8H/iR+z/4j/Zi8f8Aw2vf2kv2nfEHg7xl8IvFHhyz 8DXlp4k0PxH8Y9XstX+IGkfDLSPDnwa8FfGy9il+Nnw7+BPgzwB8CfAHxC8NfB/4f+CvBOg/ f9ABRRRQB+cFz/wTS+HvgvxVo3iX9kj9oD9p/wDYG0jS/D/ibwzcfB79lPxf8M2/ZgutO8Ta j4T1qa58P/si/tGfCP8AaF/Zc+EHiCy1zwve6+fFnwB+EHwl8VeI/EHj34m67451nxZq/jrX LyfoP+HZf7J3ij9/+0F4e+IH7Zl7d/8AEz12x/bW+LvxJ/ae+Fmp+O7j59T+KWgfsv8AxS8S a3+yL8H/AIgXs1xrUOlah8APgD8JdH+H/hzxT4r+Hvwq0LwH8MvEGoeC5fv+igDx/wCNf7PX wC/aU8K6f4F/aM+B3wf+P3gnSfEFr4s0vwd8a/hp4L+KnhXTfFVjp2q6PY+JtP8AD3jrRde0 iz8QWeka7rml2us29nHqNvp2s6rYw3KW2o3kU3gHhP8A4Jyfse+GvFXhnx1r/wAMvEHx08be AvEGjeLPhf4x/a7+M3xz/bY8VfBjxVoWo22sWfib4EeIf2vviV8b9X+BPiC61fTtC1TXdZ+E F54K1HxPqPhPwRfeJbnVrnwN4Ql0T7fooAKKKKACiiigDwD4N6J/ZXxF/axv/wDhen/C2/8A hJv2gPDmt/8ACAf2v/aX/DL/ANn/AGWP2afDn/Ci/sf/AAlPiD/hH/8AhIP+Ef8A+Gl/7I/s nwP53/DRH9vf8Itd/wBt/wDCa+MPyA+Of/Bc7/hS/wC3Z8Qf2Kf+GXf+El/4QT9v/wD4Jcfs Mf8ACy/+F2/2P/av/Dyj4O/E34s/8LR/4Q3/AIVHqv2H/hS//Cuv7A/4Qn/hK7z/AIWN/bH9 q/8ACXeBP7P/ALNvv1f+AWs/BrVPit+27Y/DDwn4g8OeNvDn7T/hPRv2jNY1m5nn07x78ZZ/ 2L/2RPEOh+LPCcU3ibXY7Pw/Z/s+a98CfAtzbWul+C4G8VeC/E143hm6ubq48Y+LPP8Axl/w Te/Yl+IPxl1v9oPxj8A/D+ufGTxH8YPg98ftb8dXHiHxxBqOofGX9nuD4T2PwM+IU1nZ+KLb SF8QfCPSPg54e8O/D2aLTo4PCnhXxp8fvCmj29r4b/aj/aW0v4sgHxBqX/Bc34J23xT8G+E9 P/Z8/aA1P4Za3+yB8S/+Cgni74t+b8IrL/hCf2CfC/iP4T6b8Ov23v8AhAp/ic3iDxJ+z/8A FHw/4v8Ail4m/wCFe6Zcxft4eCf+FP8A9ja7+xDcXvxA8OyWxP8A8F0P2cfBv/BT/wCPP/BM X406B/wrDx18O/iB+yV8Ovg/45/4TK117/hdusftTeAPDWuQz/8ACE3fh/w1e+H/APhDPib8 SPg58Iv+Ed8D698YfHetf8LP/wCFyar4R8G/AX4UfHr4k/Cr6fuf+CSf7AV14q0bxjL8FfEC 6voXh/xN8P7Gztvjz+0XZ+FZ/gZ4s1Hwnqmqfsn6z4Fs/i1B4J8R/sQWtz4L0eLwz+wt4h8P ap+x74L0688WaP4O+COhaR498dWPiP0CT/gnJ+x6P2oPHv7aOnfDLxB4a/aj+KPiD4Sa/wDE P4zeCfjN8c/AfirxhB8E/D+m+GPA/gjXE8GfErQdIvPg/eaRoPhhfiT8DX0wfBr41aj4O8Da 58ZvAnj7XPA/hLUdGAPmD/gqV/wVE8Y/8E7dY+DHh3wN+zV/w0d4g+MHw/8Ajd4y0vQoPFPx 20TWL7xH8MPHf7NHwt8AfCfwjpnwI/ZG/awvb/4gfHv4m/tO+Cfh18OtS+JMHwi+FkPju48O +Edc+Jdl4g8d+FtPuz4m/wDBav8AZY+E37J3xy/bF8V+Af2gD8Mvgr8P/wBmz442OhaZ4V+H V547+Mf7M/7YvxJuvhb+y/8AtJfC3TH+Ktv4fsvh/wDGDxBonjO80/wP8XvE/wAJ/wBoTwTo /gbXbj4qfBPwFe6n4L0/xZ9//Gr9lz4E/tEf2z/wuLwN/wAJh/wkH7P/AMff2XNX/wCKm8Y+ H/tfwJ/ag/4Vx/wvTwN/xS3iHRPs/wDwnH/CpPh9/wAVNa+T4x8M/wDCP/8AFH+IfD/9q63/ AGl4/df8E3v2JdS+DXxr/Z81z4B+H/E/wb/aB8P6V4M+I3gXxf4h8ceMNOh+HvhWfUL74a/C v4a3nijxRq2r/A74P/A7V9W1fxF+zj8IfglqPw8+Gf7NfirWNX8V/ATwp8OfEmqX+qXAB8wR /wDBY74J+Ef2sfG/7JP7QXwx+IH7Pfi2P9r/AEf9kb4GeJvF3ij4ReI9H+Pmsaz8Nv2b/Flt 4v8ADujeDfiFrHi3S/O8W/tZfs7eHoPAVnoXifx3b+BPjv8ADr4x69pGgeEvh1+2rbfsc/f/ AOzr+0Jo/wC0j4c+I/izw54D+IHgrw/8P/2gPj5+z3Zah4/XwJF/wsLWP2cvin4m+Cnj/wAe eCrXwV478bXtt8P7n4m+CfGvhnw43j+28C+O9R/4Re91m88CaZ4f1Pw5qut+f3v7CP7M938d vEf7S8Phf4gaJ8bfF3xA8FfEvxF418JfH/8AaE8Ff2l4j8D+DvAHgCDTX8OeEfinonhK3+H/ AI48JfCT4P6T8bvhPaaDb/Cz9oj/AIU18Gr/AOPXg34kan8JPh1e+Gff/hp8LfAnwf8ADmpe E/h1oX/CO+H9X+IHxZ+KWoaf/aesav8AaPHfxx+KfjL41/FLXftWu6hqd7F/wlHxN+IHi7xN /ZkFzFo+if2v/Y3h3T9I8P2GmaVZAHoFFFFABRRRQAV/OF8X/wDgrL4V/Zw/4KrftxeBfD37 Df8AwUf/AGtNX+HfwB/YW+Cnjq4/Yx/Zn0748ad4R8VaPF+0t+0ZZ6h4lmsfiPodzoHh/wAU +Cf2q/B2l+ErrWLOx1HW/FXgb4qWMWlRaR4Z0vXPEX9HtfiFrf8AwTx/Zg+P37cH/BW34RfH bwr4g+K3wp/be+AP/BLn41/G/wABaz4x8QeFtOk8VfDDxZ+1H8MvCGn+E9e+Gd34F8beH/D9 lbfssfDDxVc2reKr/Ub7xVJ4mF1qsnhbVrfwvpwB+P8A+yt/wUf+KfwO/wCCk/8AwVa/bF8W f8Edv+C32o/DL9uj/hhj/hUmheHf+CfHiO78d+Hf+GZPgL4i+Fvj3/hYumal450jw/pH9r+I NXtrzwj/AMIz4n8Xfb9HSe41n+wL1Y9Pl/SCP/gqn8LP+CiXgL4s/C3wn+zt+1/+zP8AE39k /wDbe/4Izf8AC2/h1+2L8I/DnwZ8d2P/AAvX/goV8BfEXgL7H4R034h+NvEFt9p8P+CLnXbj /hJtP8Oedo+veGNT0b+17LVJJ7T8oP2NP+CCv/BJ74r/APBWL/gtB+zR4/8A2U/7f+CX7Jv/ AA7p/wCGf/BX/C8/2ktL/wCEB/4Xv+zb4o8f/Fb/AIqPRfjFp3i3xV/wlXi3TrPVv+K117xH /Yfk/YPDn9j6ZJLZP+7/AO1B+xT8LPgd45/aT/bF8J6/8QNR+Jv7dH7b3/BED/hbeheItV8O XfgTw7/wzJ+2z+zL8LfAX/CutM03wppHiDSP7X8P6vc3ni7/AISbxP4u+36wkFxo39gWSyaf KAfs7RRRQAV8gfFL9uj9n/4SeO9d+G2swftAeO/FvhT+zIPGNt+z3+x3+1/+1Ro/gfWNY0fT /E2neEfHniz9mb4F/Fvwl4H+IFx4S1vwz42b4deLNc0fx3b+BPGXgTxzc+HYfCXjvwfrOt/X 9fAH/BNP/k3X4jf9n/8A/BWL/wBem/tkUAfIH/BQn9tr4YfHH9gX9uH4KfC34Oft/wDij4m/ GD9kD9pb4W/Drwz/AMOsP+Cmuif8JF47+IHwX8a+E/COhf2z4i/ZH0jw/pH9r+INX0/T/wC0 9d1XTNHsPtH2rU9QsrKKe5iP+Ce37bXww+B37Av7D3wU+KXwc/b/APC/xN+D/wCyB+zT8Lfi L4Z/4dYf8FNdb/4R3x38P/gv4K8J+LtC/tnw7+yPq/h/V/7I8QaRqGn/ANp6Fqup6Pf/AGf7 VpmoXtlLBcy/t9RQB8gfC39uj9n/AOLfjvQvhto0H7QHgTxb4r/tODwdbftCfsd/tf8A7K+j +ONY0fR9Q8Taj4R8B+LP2mfgX8JPCXjj4gW/hLRPE3jZfh14T1zWPHdx4E8G+O/HNt4dm8Je BPGGs6J9f18Af8FLP+Tdfhz/ANn/AP8AwSd/9em/sb19/wBABRRRQAV4B+zTrf8AwkHw68R3 /wDwov8A4Z3+z/tAftY6J/wgH9kf2J/wkH/CM/tT/GTw5/wvT7H/AMIt4P8AO/4ag/sr/hpf +1/7Ju/+Eg/4W3/b3/CU+OP7S/4TXxB7/Xj/AMD9G+Mug+C9asfjt4s8P+NPG0/xg/aF1nQ9 Y8M20Frp1n8GvEfx9+JfiH9nPwncxW/hnwnG3iDwF+z5qnww8C+LLltLup7zxV4c1m8uvE3j S5nm8Y66AewUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFAHj/AMNNZ+MuqeNP2hbH4n+E/D/hzwT4c+MGi6N+znrGjXME+o+P fg1P8Avgf4h1zxZ4sih8Ta7JZ+ILP9oPXvjt4Ftra60vwXO3hXwX4ZvF8M3VtdW/jHxZ7BXg Hwb0T+yviL+1jf8A/C9P+Ft/8JN+0B4c1v8A4QD+1/7S/wCGX/s/7LH7NPhz/hRf2P8A4Snx B/wj/wDwkH/CP/8ADS/9kf2T4H87/hoj+3v+EWu/7b/4TXxh7/QAUUUUAFFFFABRRRQAUUUU AFFFFABXxD4C/wCUkX7V/wD2ZD/wT6/9Xx/wU0rz79p/wn4V+PH7aH7LP7K/xo8M+H/ij+zd 40/Zg/bX+O/jz4H+OdG07xH8M/iL8TPgf8Vv2C/Anwl1T4k+EtStp9I+Ivh/wJpH7Q/xR1nQ /AHja2174exfEK68E/FefwtP8UfhJ8I/GHgb5h8Ff8Eyf+Cbd5+3x+0t4FvP+CfP7EF14J8O fsg/sP8Aizw94Ouf2UPgNP4V0HxV40+M/wDwUI0fxj4m0bw9L4BbSNL8QeLNI8BeBdL8TazY 2cGo69p3gvwnY6pc3Vt4c0eKzAPPv+CeH/Kdf/g4q/7xG/8ArHnjav0g/wCCgv8AyQfwF/2e 9/wTL/8AXkX7KFc9/wAOnf8Agll/0jT/AGAP/EN/2df/AJ3NfIP7cH/BMn/gm34L+DHgrWPB 3/BPn9iDwnq95+19/wAE9/Cd5qnhn9lD4DaDqN14V8e/t8fs1eBfHXhm5vtL8A2tzP4f8aeC fEfiHwd4s0aWVtO8R+Fde1nw9rFteaRql9ZzgH7e0V8Qf8E8vFnirxZ+zdfxeLfE3iDxdc/D z9p/9vD4EeGtb8WazqPifxU3wz/Zw/bp/aN+AHwg0vxN4v1251DxT458QeHvhT8NPBnh7WfH /jjWPEXxC8e6jpdz4x+IfinxV421vX/Eeqfb9ABXwB/wTg/4l3wX+NXg/UP9A8W+Dv2//wDg pb/wl3ha9/0XxH4V/wCFlft9ftFfHT4df8JJok+zU9D/AOE++CXxX+Fvxi8Ff2na2v8AwlXw s+JXgD4haF9v8JeMfDur6j9/18wfGv8AYi/Yv/aU8Vaf46/aM/ZE/Zg+P3jbSfD9r4T0vxj8 a/gF8Kfip4q03wrY6jqusWPhnT/EPjrwnr2r2fh+z1fXdc1S10a3vI9Ot9R1nVb6G2S51G8l mAPp+ivgD/h07/wSy/6Rp/sAf+Ib/s6//O5o/wCHTv8AwSy/6Rp/sAf+Ib/s6/8AzuaAD/go /wD8TH4L/BXwfp/+n+LfGP7f/wDwTS/4RHwtZ/6V4j8Vf8K1/b6/Z1+OnxF/4RzRIN+p65/w gPwS+FHxS+MXjX+zLW6/4RX4WfDXx/8AELXfsHhLwd4i1fTvv+vmD4KfsRfsX/s1+KtQ8dfs 5/sifswfAHxtq3h+68J6p4x+CnwC+FPwr8Val4VvtR0rWL7wzqHiHwL4T0HV7zw/eavoWh6p daNcXkmnXGo6NpV9NbPc6dZyw/T9ABRRRQAV8wfsiaN8GtB+FPiyx+BPizxB408Ez/tP/tu6 zrmseJrae11Gz+MviP8AbQ+PviH9ozwnbRXHhnwnI3h/wF+0HqnxP8C+E7ldLuoLzwr4c0a8 tfE3jS2nh8Y679P14B+zTrf/AAkHw68R3/8Awov/AIZ3+z/tAftY6J/wgH9kf2J/wkH/AAjP 7U/xk8Of8L0+x/8ACLeD/O/4ag/sr/hpf+1/7Ju/+Eg/4W3/AG9/wlPjj+0v+E18QAHv9FFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQB8wfALWfg1qnxW/bdsfhh4T8QeHPG3hz9p/wAJ6N+0ZrGs3M8+nePfjLP+xf8AsieI dD8WeE4pvE2ux2fh+z/Z8174E+Bbm2tdL8FwN4q8F+JrxvDN1c3Vx4x8WfT9eP8Aw01n4y6p 40/aFsfif4T8P+HPBPhz4waLo37OesaNcwT6j49+DU/wC+B/iHXPFniyKHxNrsln4gs/2g9e +O3gW2trrS/Bc7eFfBfhm8XwzdW11b+MfFnsFABRRRQAUUUUAFFFFABRRRQAUUUUAfnJ8bdJ v9e/4KU/sr6FpXifXPBWqa1/wTk/4KhaTpvjLwxb+G7vxJ4Sv9R+Pf8AwSls7PxP4etfGXh7 xb4Qudc0G4mj1XSbfxX4U8TeG5r+0t49d8Pa1pbXWm3P87X/AATR8Tf8Fr/Hf/Baf41fBH9q z9oX/Q/2ePA/w4079sbxf4G+GPwIbwr8Rfhd4Dl8efED9ln4ceFfGOi/s832h6F/wtnXP2g/ EXjq3sbqD4S/F7WvgxffFWKfWfC/xD+G+kaP4U/SL4lf8FU/2Fv2jf2h/BfwTPiP9p/9k/47 eAf2n/8AgpT+yf4T/bM0aw/Zu8Had8EtR/4J9fCT4b/GT9szVvFniz4r+I/it8O7/wDZg+J/ w71bwrNbaP8AF34OePvCup+KvAfhn4qeKvh38LviT8F/g38V/BvyJ8Wf+Cin7PPwK0j9rv4z 6/8A8FFf+C0dj49/Zu0PwHovxM0vWv8AgnZ+wJ8E/i/8U/hxovij9miw0t/B+oftFf8ABLD4 KWeq6H8JPGn/AAUU+HUt98NPiX4t8C/ETwzbfEzxB8SvDPw5vvh18RvBXjn4jgH9bNfyk/8A BaT/AILE/Fj9nH9pfwv+wHa/sK658S9U1r4p/sOftC/A3xv4Y+OMN34k+Odh8O/2lPhT8X7H wp4e+EPhn4Q+Mtf0bXPF/wAV/g14y+Aek2F5r174ke/tLfx3pvhXWtL1PQtE1j6Ytf2mPhf4 j8K/8FDfEPw1/wCC1H/BR/4rav8A8EufD/xH1n9sHwL4T/Z1/wCCdWheKvBeo/DDTvi1fa74 T8M3nxP/AOCXHw98E+O/EF9c/BD4jaPo1z4X8Y3/AIVn1HR7aW/8TabpGraXql188+JtM/YJ /ak8Rfs1ftZ/Gr/gr9+1/rdz+z544/aK1H9n742/ETwP/wAE0NT+B3wWTwv8fPGP7Nx/aB8f /E/wL/wTz8RfsrfDX4f/AB7+J37M+pH9i34o/tNeKdCt/ix4m8N6e/7PIT436BqeieGwD9if +CVtx4ku/wBlHxNdeMtJ0PQfF9z+3H/wVMuPFeheGPEN/wCLfDei+JJv+Cn37YMmu6T4e8V6 r4Y8Fap4m0PTtUa6s9J8Q6l4N8JX+tWENvqV54Y0G4uZNKtP0br4A/YV/aQ/ZO+KfhzS/hV+ yLo/xAg+GWg/s/8Awc/ae8LeLPGvgj4k+Df+Fi+BP2qvin+05o2ifES9ufjpHpPx68c/ED4l +Ov2fPin8WfH/wAVPir4cfWPjR/wsTw38bl+IHxPvfiZq/iYff8AQAUUUUAFFFFABRRRQAUU UUAFeP8AwP0b4y6D4L1qx+O3izw/408bT/GD9oXWdD1jwzbQWunWfwa8R/H34l+If2c/CdzF b+GfCcbeIPAX7PmqfDDwL4suW0u6nvPFXhzWby68TeNLmebxjrvsFfMH7ImjfBrQfhT4ssfg T4s8QeNPBM/7T/7bus65rHia2ntdRs/jL4j/AG0Pj74h/aM8J20Vx4Z8JyN4f8BftB6p8T/A vhO5XS7qC88K+HNGvLXxN40tp4fGOugH0/RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfIHwb8e/CzSv2mP2sfg1/wANf/D/ AOLfxt8TfEDw58dP+GXv+Fk+HNS+Kf7L/wALLf8AZ7/Zp+Fn/CLf8Kx/4TrxB4t8P/D/AMQe LfD/APwu7+2/+ES8D+HJvEf7RG/+yLvU9b/4Szxh0Gjftu/sX+I/g14s/aM8Pftd/swa7+z5 4C8QW3hPx18dtG+Pvwp1T4NeC/FV5P4ZtbPwz4s+J9j4sn8E+HPEF1c+NPB1vbaNrGuWeozz +LPDMMVs0mvaWt19P0UAeAa3+1j+yx4Z/wCFF/8ACR/tLfs/+H/+GoP7I/4Zo/tv4yfDrSv+ GiP+Eg/4Rb+wf+FF/b/Edv8A8Lb/ALb/AOE48Ff2R/wgH/CQf2l/wmHhb7H53/CQaT9r39G/ aF+AXiP4y+LP2c/D3xx+D+u/tB+AvD9t4s8dfAnRviX4L1T4y+C/Ct5B4ZurPxN4s+GFjrU/ jbw54furbxp4OuLbWdY0Oz06eDxZ4ZmiuWj17S2uvYKKAPmDRv23f2L/ABH8GvFn7Rnh79rv 9mDXf2fPAXiC28J+Ovjto3x9+FOqfBrwX4qvJ/DNrZ+GfFnxPsfFk/gnw54gurnxp4Ot7bRt Y1yz1GefxZ4Zhitmk17S1uug1v8Aax/ZY8M/8KL/AOEj/aW/Z/8AD/8Aw1B/ZH/DNH9t/GT4 daV/w0R/wkH/AAi39g/8KL+3+I7f/hbf9t/8Jx4K/sj/AIQD/hIP7S/4TDwt9j87/hINJ+1+ /wBFAHj+jftC/ALxH8ZfFn7Ofh744/B/Xf2g/AXh+28WeOvgTo3xL8F6p8ZfBfhW8g8M3Vn4 m8WfDCx1qfxt4c8P3Vt408HXFtrOsaHZ6dPB4s8MzRXLR69pbXXAaN+27+xf4j+DXiz9ozw9 +13+zBrv7PngLxBbeE/HXx20b4+/CnVPg14L8VXk/hm1s/DPiz4n2PiyfwT4c8QXVz408HW9 to2sa5Z6jPP4s8MwxWzSa9pa3X0/RQB4Brf7WP7LHhn/AIUX/wAJH+0t+z/4f/4ag/sj/hmj +2/jJ8OtK/4aI/4SD/hFv7B/4UX9v8R2/wDwtv8Atv8A4TjwV/ZH/CAf8JB/aX/CYeFvsfnf 8JBpP2vf0b9oX4BeI/jL4s/Zz8PfHH4P67+0H4C8P23izx18CdG+JfgvVPjL4L8K3kHhm6s/ E3iz4YWOtT+NvDnh+6tvGng64ttZ1jQ7PTp4PFnhmaK5aPXtLa69A8TeLPCvgvTrbWPGPibw /wCE9IvPEHhPwnZ6p4m1nTtB0668VePfFWjeBfAvhm2vtUubW2n8QeNPG3iPw94O8J6NFK2o +I/FWu6N4e0e2vNX1Sxs5zxN4s8K+C9OttY8Y+JvD/hPSLzxB4T8J2eqeJtZ07QdOuvFXj3x Vo3gXwL4Ztr7VLm1tp/EHjTxt4j8PeDvCejRStqPiPxVrujeHtHtrzV9UsbOcA8A0b9t39i/ xH8GvFn7Rnh79rv9mDXf2fPAXiC28J+Ovjto3x9+FOqfBrwX4qvJ/DNrZ+GfFnxPsfFk/gnw 54gurnxp4Ot7bRtY1yz1GefxZ4Zhitmk17S1uug1v9rH9ljwz/wov/hI/wBpb9n/AMP/APDU H9kf8M0f238ZPh1pX/DRH/CQf8It/YP/AAov7f4jt/8Ahbf9t/8ACceCv7I/4QD/AISD+0v+ Ew8LfY/O/wCEg0n7X7/XP+E/FnhXx74V8M+OvAvibw/408E+NPD+jeLPB3jHwnrOneI/Cviz wr4j0621jw94m8M+IdHubzSNe8P67pF5Z6po2s6XeXWnapp11bX1jcz208UrAH5gaB+xt/wR +1/9qDxv8PNH8HfsweNv2sPCfiD45fH74ofBK8+Kdl49+Jmj6j+1n4f8d6H+0R8QviZ8BNX8 da5cx+H/ANoTwR+1HF4S+KU3jHwO3hX4i/D1v2ZPBniG31Twd8AP2WtI+GfzBf8A7Ev/AAQP +MHwJ/aI+O/if4x/D/44/s5eOfs/wt/aQ+PfxC/4Kn/tEfGr4WW+sX/jH9lLxPHoXjD4z+N/ 2uPFvh/wJ8QNY8Qfs/8A7HWl3Wp2/inw7471vw54C+DvgC81C88GS6P4cvf2+8FfFj4WfEr7 H/wrr4l/D/x9/aPw/wDAHxY0/wD4Qrxl4c8Vfb/hZ8V/+Ej/AOFW/Euz/sLUr/7V8P8A4lf8 Id4u/wCEA8ZQb/DnjH/hFfEf/CO6lqP9h6n9l9AoA/MCfwD/AMEwPAfgTxd8Lde+N3w/074Z f8FaP+Fi/wBh/Drx7+3H4/1bwJ+09/w03rHiLxF8Sf8Ahkbwj42+O2oeH/D3/C5vEH7S97ru r/8ADIen+Ef+Ep1j4meENTi8+9bwNPaE/wCzT/wTA+I3xs8Xfs+6T4j+H9x+0b4J/wCFi/Fj 4nfBH4a/tY+P/Cfxs0//AIXB8XfEX7SrfEv4ufDb4cfGTRPHWo/8K9+PX7SOsfH/APZd8ZfE TRb3/hkj4u/FnS/ir+yfqXwc8Z634f14/f8AP8WPhZbeBPF3xSufiX8P7f4ZfD//AIWL/wAJ 78RZ/GXhyLwJ4J/4U/rHiLw78W/+Eu8XSakvh/w3/wAKu8QeEPFmhfEX+2dQsv8AhCdY8L+I tM8Tf2Ze6JqUFt6BQB+cHwD8df8ABLn4R/DP4hftW/AX9oL9mC1+DeheH/h98CPi/wDtJ6b+ 1J4Z8c/DO2n8F/EL4h/Ejw1pfxb+MWv/ABN8SeFrn4weJPit+19498e+PfH/AI78Rz/GX4x/ EL46R+Kfij4p8a+JPEehXzfUGt/tY/sseGf+FF/8JH+0t+z/AOH/APhqD+yP+GaP7b+Mnw60 r/hoj/hIP+EW/sH/AIUX9v8AEdv/AMLb/tv/AITjwV/ZH/CAf8JB/aX/AAmHhb7H53/CQaT9 r9/ooA8f0b9oX4BeI/jL4s/Zz8PfHH4P67+0H4C8P23izx18CdG+JfgvVPjL4L8K3kHhm6s/ E3iz4YWOtT+NvDnh+6tvGng64ttZ1jQ7PTp4PFnhmaK5aPXtLa64DRv23f2L/Efwa8WftGeH v2u/2YNd/Z88BeILbwn46+O2jfH34U6p8GvBfiq8n8M2tn4Z8WfE+x8WT+CfDniC6ufGng63 ttG1jXLPUZ5/FnhmGK2aTXtLW6+n65+28WeFbzxVrPgWz8TeH7rxt4c8P+GfFniHwdbazp0/ irQvCvjTUfFmj+DvE2s+HorltX0vw/4s1fwF460vwzrN9Zwadr2o+C/FljpdzdXPhzWIrMA8 g1v9rH9ljwz/AMKL/wCEj/aW/Z/8P/8ADUH9kf8ADNH9t/GT4daV/wANEf8ACQf8It/YP/Ci /t/iO3/4W3/bf/CceCv7I/4QD/hIP7S/4TDwt9j87/hINJ+17+jftC/ALxH8ZfFn7Ofh744/ B/Xf2g/AXh+28WeOvgTo3xL8F6p8ZfBfhW8g8M3Vn4m8WfDCx1qfxt4c8P3Vt408HXFtrOsa HZ6dPB4s8MzRXLR69pbXXsFFAHzBo37bv7F/iP4NeLP2jPD37Xf7MGu/s+eAvEFt4T8dfHbR vj78KdU+DXgvxVeT+GbWz8M+LPifY+LJ/BPhzxBdXPjTwdb22jaxrlnqM8/izwzDFbNJr2lr ddBrf7WP7LHhn/hRf/CR/tLfs/8Ah/8A4ag/sj/hmj+2/jJ8OtK/4aI/4SD/AIRb+wf+FF/b /Edv/wALb/tv/hOPBX9kf8IB/wAJB/aX/CYeFvsfnf8ACQaT9r9/ooA8f0b9oX4BeI/jL4s/ Zz8PfHH4P67+0H4C8P23izx18CdG+JfgvVPjL4L8K3kHhm6s/E3iz4YWOtT+NvDnh+6tvGng 64ttZ1jQ7PTp4PFnhmaK5aPXtLa64DRv23f2L/Efwa8WftGeHv2u/wBmDXf2fPAXiC28J+Ov jto3x9+FOqfBrwX4qvJ/DNrZ+GfFnxPsfFk/gnw54gurnxp4Ot7bRtY1yz1GefxZ4Zhitmk1 7S1uvp+igDwDW/2sf2WPDP8Awov/AISP9pb9n/w//wANQf2R/wAM0f238ZPh1pX/AA0R/wAJ B/wi39g/8KL+3+I7f/hbf9t/8Jx4K/sj/hAP+Eg/tL/hMPC32Pzv+Eg0n7Wfs063/wAJB8Ov Ed//AMKL/wCGd/s/7QH7WOif8IB/ZH9if8JB/wAIz+1P8ZPDn/C9Psf/AAi3g/zv+GoP7K/4 aX/tf+ybv/hIP+Ft/wBvf8JT44/tL/hNfEHv9FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH 5gf8FhPhb4E+OP7EUvwU+KWhf8JR8MvjB+1//wAEz/hb8RfDP9p6xon/AAkXgT4gf8FK/wBk jwn4u0L+2fDuoaR4g0j+1/D+r6hp/wDaeharpmsWH2j7VpmoWV7FBcxflD8c/E3xl/alsv2d fDv7Rlt4g1DV/wDgmF+2/wD8E09B8X+N9V8JweE4Pj/+214h/wCCwPgL9krRP2grrRfDmjeE tO+DXiC4/Yv8Aa5+05p/7O1vd+OfA+p/Br/grX8FPG0Nm2kfDT4AfFz4kf0++JvCfhXxpp1t o/jHwz4f8WaRZ+IPCfiyz0vxNo2na9p1r4q8BeKtG8deBfE1tY6pbXVtB4g8F+NvDnh7xj4T 1mKJdR8OeKtC0bxDo9zZ6vpdjeQc/e/Cf4Waj/wkf9ofDT4f3/8AwmPxA8FfFjxd9t8G+HLr /hKvin8Nf+EA/wCFdfEvxH5+mv8A258QPAP/AAqj4W/8IV4y1P7V4j8K/wDCtfAH9halYf8A CHeHf7OAPyh+FH7RX7Q+rfGX9nr4n698ZvEGu+Cf2mf+Cj//AAUA/YQ1b9nS98IfCS0+DXww +Hv7I8H/AAUTh+H3xL+F+uaL8OdK/aDPxg8TSfsIeArrx9efE347fEz4Z38/xS+Mi+F/hf4R trr4WW/wp8f/AOCQXjD47fDz4Wf8EpPg744+MX/C0fh/+0b/AMEgLD46af4Pl+Hvg7wZ4c+B n/DNPhz/AIJ9/D34W+FvhTdaFazfEDVf+Ew+H/7UGq3X7QGt/GP4hfFb/hM/in4M0Xxh8FtI /Zy+H+o6n8HX/Z7Rv2evgF4c+Mviz9ozw98Dvg/oX7Qfj3w/beE/HXx20b4aeC9L+MvjTwrZ weGbWz8M+LPifY6LB428R+H7W28F+Dre20bWNcvNOgg8J+GYYrZY9B0tbXA+Bf7J37LH7L// AAlP/DNH7NP7P/7O/wDwnH9if8Jr/wAKL+Dfw6+En/CYf8Iz/a//AAjf/CU/8IB4c8P/APCQ f8I//wAJBr39if2t9r/sr+29X+wfZ/7SvPOAP54fAf7Xn7Q9n8KZ/wBqWwvfEHjr9pH4/f8A BKD/AINktG8Ua74M0H4SWPxC17xp+2p+2h+2D8IPib4s+FegePZfB/7PmjfGAx/GrxR4k+EN t8SrWy+AWg/EyPwo/wARvDOo/C6y17w1efs9/wAE9/iL+0B428HfHjwz+0PB8QIvEHwf/aAf 4deDJPjj4i/ZA1v9pi58Can8CfgV8W4p/wBpLTf2FvF3iT9nLwh8QF8Z/FHxpbeB/DvhbRvh /rFz+z3b/BTxZ4r8I3viDxRfePfG30/bfs9fAKz8K6z4Fs/gd8H7XwT4j+D/AIZ/Z68Q+Drb 4aeC4PCuu/ALwXp3izR/B3wO1nw9Foq6Rqnwf8J6R498daX4Z+Gl9Zz+C9B07xp4ssdL0W1t vEesRXnQfC34T/Cz4HeBNC+FvwU+Gnw/+D/wy8L/ANp/8Iz8Ovhb4N8OfD/wJ4d/tvWNQ8Ra z/YXhHwnpukeH9I/tfxBq+q67qf9n6fb/b9Y1PUNTuvNvb25nlAP5Qvjp/xjN/wTx/4Ke/GC D/iXfBL9tH/iIH+AXxw2f6H4c8FftT+Ff2tf+Cjf/DLHxq1jZ/YHhLw5/wAL38JR+Iv2O/if 8R/F2p+KviL8T/inov8AwTF/Z8+HWjW+madfY/R//gop+1h+2Z8PPj78d/B37Nmk/GCXSP2W v2IPhZ+1hpt54A1j/gn94N+AWqfEL4j+NP2wdLOk/wDBQDx1+3D8RPAvjbw/+zBZW37LHheW 51j9kLxD8OPiZ4Y8F6v8fdY8W/ES01eX4N33hX9np/hP8LLnwJ4u+Ftz8NPh/cfDL4gf8LF/ 4T34dT+DfDkvgTxt/wALg1jxF4i+Lf8Awl3hGTTW8P8AiT/haPiDxf4s134i/wBs6fe/8Jtr HijxFqfib+073W9Snuef+I/7PXwC+Mfir4Y+Ovi78Dvg/wDFTxt8E/EDeLPgz4x+I/w08F+O PFXwj8VPqPh/WH8TfDHxD4n0XVNX8BeIG1fwn4V1RtZ8K3mk6i2o+GvD98bk3OjadLbAH4w+ F/EHxd/Zk+NH/BTb9oaz+OvxA8ZfDLwV/wAFf/2ZZ/j58PvGvhr4J2Pg7Tv2cfif+wL+xD8P PiP4uvfiF4Z+EnhzxB8K/h/+yz4f/aK8AftB+P8A4i+I9T161X4E/sDeHPD3jXxF4SvfiJ+0 V8fPF3j83/BSn9vOx+BnxX8V+Ifhr4g+E3xW/Zi/Zg/bN/4KRfEnRPjB8N3n07VfhnqH7Hvg X4//ALI/7HnxR8IQ+C/hV4k8C+H/AAb8ZP2svGP7Pmn/ABt0fxF4U+IXxy8Vf8Eav2kNOlsL HxT8Qfjp4c+A37/XX7PXwCvtR+NesX3wO+D95q/7Snh/SvCf7ReqXXw08F3Go/H7wroXhXUP Auh+GfjXfTaK9z8VPD+jeCdW1TwdpWjeOpde07TvCupah4es7aHSLy4s5PQLbwn4Vs/FWs+O rPwz4ftfG3iPw/4Z8J+IfGNto2nQeKtd8K+C9R8Wax4O8M6z4hitl1fVPD/hPV/HvjrVPDOj X15Pp2g6j408WX2l21rc+I9YlvAD8Yfjn8cf2mP2V/hZ/wAFbvh7Z/tJfED40eLf2V/+CYGi ftrfBH46fGLwP+z3D8U/CnxT+I3hz9v3RE0C60j4NfBP4PfBLxH8P/BGp/sieAPGHg/SvEfw d1XxHN4j8V/EK18a+K/GXhK+8JeFvBvj/wAQPiT+0P8AAH/goD8Rfh1q/jbxBrur/HH9mD/g ll8JPjl+3fpPgb4SaT4V/Zo1H43ftmf8FTvBvw+j+Hf7Pd9rmv8AiTWPEHxF+MnxN+Hv7MX7 J+m614V/aG8K/A/TtW0f46fttePfjjpHwn8a2X7Q37P+AP2Tv2WPhR8LPGvwL+Fv7NP7P/w1 +CXxK/4SP/hYvwd8AfBv4deDvhZ4+/4THw5Z+D/F3/Ca/D3w74c07wl4q/4Srwlp2n+FvEf9 u6Rf/wBueHLCz0TU/tWmWsFqnf8AiP4T/Czxj/wn/wDwl3w0+H/ir/ha/wAP7P4T/FL/AISP wb4c1z/hZXws07/hNf7P+Gnj/wDtPTbr/hMfh/Yf8LK+Iv2Pwb4i/tHw5a/8J9418jTU/wCE q137eAegUUUUAFFFFABRRRQAUUUUAf/Z --------------46B1D4483E2F15487BE06550-- --------------EC1A0CF251C176391AE5186D-- --------------CB49B1CED950610369ECF7C6 Content-Type: application/postscript; name="mobilenet.eps" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="mobilenet.eps" Content-Transfer-Encoding: base64 xdDTxh4AAAAw/AEAAAAAAAAAAABQ/AEAMIMAAP//JSFQUy1BZG9iZS0zLjAgRVBTRi0zLjAN CiUlQ3JlYXRvcjogSW1hZ2VNYXJrIFNvZnR3YXJlIExhYnMNCiUlRm9yOiAoKSAoKQ0KJSVU aXRsZTogbW9iaWxlbmV0LmVwcw0KJSVDcmVhdGlvbkRhdGU6ICgpICgpDQolJUJvdW5kaW5n Qm94OiA0NC43NTAwIDIyLjAwMDAgNTU4LjUwMDAgNzg4Ljc1MDANCiUlRG9jdW1lbnRQcm9j ZXNzQ29sb3JzOiBCbGFjaw0KJSVDb2xvclVzYWdlOkNvbG9yDQolJURvY3VtZW50Rm9udHM6 IEhlbHZldGljYQ0KDQolJURvY3VtZW50U3VwcGxpZWRSZXNvdXJjZXM6IHByb2NzZXQgQWRv YmVfcGFja2VkYXJyYXkgMi4wIDANCiUlKyBwcm9jc2V0IEFkb2JlX2NteWtjb2xvciAxLjEg MA0KJSUrIHByb2NzZXQgQWRvYmVfY3Nob3cgMS4xIDANCiUlKyBwcm9jc2V0IEFkb2JlX2N1 c3RvbWNvbG9yIDEuMCAwDQolJSsgcHJvY3NldCBBZG9iZV90eXBvZ3JhcGh5X0FJMyAxLjAg MA0KJSUrIHByb2NzZXQgQWRvYmVfSWxsdXN0cmF0b3JfQUkzIDEuMCAwDQolQUkzX0NvbG9y VXNhZ2U6IENvbG9yDQolQUkzX1RlbXBsYXRlQm94OiA0NC43NTAwIDIyLjAwMDAgNTU4LjUw MDAgNzg4Ljc1MDANCiVBSTNfVGlsZUJveDogNDQuNzUwMCAyMi4wMDAwIDU1OC41MDAwIDc4 OC43NTAwDQolQUkzX0RvY3VtZW50UHJldmlldzogTm9uZQ0KJSVUZW1wbGF0ZToNCiUlUGFn ZU9yaWdpbjo0NC43NTAwIDIyLjAwMDANCiUlRW5kQ29tbWVudHMNCiUlQmVnaW5Qcm9sb2cN CiUlQmVnaW5SZXNvdXJjZTogcHJvY3NldCBBZG9iZV9wYWNrZWRhcnJheSAyLjAgMA0KJSVU aXRsZTogKFBhY2tlZCBBcnJheSBPcGVyYXRvcnMpDQolJVZlcnNpb246IDIuMA0KJSVDcmVh dGlvbkRhdGU6ICg4LzIvOTApICgpDQolJUNvcHlyaWdodDogKChDKSAxOTg3LTE5OTAgQWRv YmUgU3lzdGVtcyBJbmNvcnBvcmF0ZWQgQWxsIFJpZ2h0cyBSZXNlcnZlZCkNCnVzZXJkaWN0 IC9BZG9iZV9wYWNrZWRhcnJheSA1IGRpY3QgZHVwIGJlZ2luIHB1dA0KL2luaXRpYWxpemUN CnsNCi9wYWNrZWRhcnJheSB3aGVyZQ0Kew0KcG9wDQp9DQp7DQpBZG9iZV9wYWNrZWRhcnJh eSBiZWdpbg0KQWRvYmVfcGFja2VkYXJyYXkNCnsNCmR1cCB4Y2hlY2sNCnsNCmJpbmQNCn0g aWYNCnVzZXJkaWN0IDMgMSByb2xsIHB1dA0KfSBmb3JhbGwNCmVuZA0KfSBpZmVsc2UNCn0g ZGVmDQovdGVybWluYXRlDQp7DQp9IGRlZg0KL3BhY2tlZGFycmF5DQp7DQphcnJheSBhc3Rv cmUgcmVhZG9ubHkNCn0gZGVmDQovc2V0cGFja2luZw0Kew0KcG9wDQp9IGRlZg0KL2N1cnJl bnRwYWNraW5nDQp7DQpmYWxzZQ0KfSBkZWYNCmN1cnJlbnRkaWN0IHJlYWRvbmx5IHBvcCBl bmQNCiUlRW5kUmVzb3VyY2UNCg0KQWRvYmVfcGFja2VkYXJyYXkgL2luaXRpYWxpemUgZ2V0 IGV4ZWMNCg0KJSVUaXRsZTogKENNWUsgQ29sb3IgT3BlcmF0b3JzKQ0KJSVWZXJzaW9uOiAx LjEgDQolJUNyZWF0aW9uRGF0ZTogKDEvMjMvODkpICgpDQolJUNvcHlyaWdodDogKChDKSAx OTg3LTE5OTAgQWRvYmUgU3lzdGVtcyBJbmNvcnBvcmF0ZWQgQWxsIFJpZ2h0cyBSZXNlcnZl ZCkNCmN1cnJlbnRwYWNraW5nIHRydWUgc2V0cGFja2luZw0KdXNlcmRpY3QgL0Fkb2JlX2Nt eWtjb2xvciA0IGRpY3QgZHVwIGJlZ2luIHB1dA0KL2luaXRpYWxpemUNCnsNCi9zZXRjbXlr Y29sb3Igd2hlcmUNCnsNCnBvcA0KfQ0Kew0KdXNlcmRpY3QgL0Fkb2JlX2NteWtjb2xvcl92 YXJzIDIgZGljdCBkdXAgYmVnaW4gcHV0DQovX3NldHJnYmNvbG9yDQovc2V0cmdiY29sb3Ig bG9hZCBkZWYNCi9fY3VycmVudHJnYmNvbG9yDQovY3VycmVudHJnYmNvbG9yIGxvYWQgZGVm DQpBZG9iZV9jbXlrY29sb3IgYmVnaW4NCkFkb2JlX2NteWtjb2xvcg0Kew0KZHVwIHhjaGVj aw0Kew0KYmluZA0KfSBpZg0KcG9wIHBvcA0KfSBmb3JhbGwNCmVuZA0KZW5kDQpBZG9iZV9j bXlrY29sb3IgYmVnaW4NCn0gaWZlbHNlDQp9IGRlZg0KL3Rlcm1pbmF0ZQ0Kew0KY3VycmVu dGRpY3QgQWRvYmVfY215a2NvbG9yIGVxDQp7DQplbmQNCn0gaWYNCn0gZGVmDQovc2V0Y215 a2NvbG9yDQp7DQoxIHN1YiA0IDEgcm9sbA0KMw0Kew0KMyBpbmRleCBhZGQgbmVnIGR1cCAw IGx0DQp7DQpwb3AgMA0KfSBpZg0KMyAxIHJvbGwNCn0gcmVwZWF0DQpBZG9iZV9jbXlrY29s b3JfdmFycyAvX3NldHJnYmNvbG9yIGdldCBleGVjDQpwb3ANCn0gZGVmIA0KL2N1cnJlbnRj bXlrY29sb3INCnsNCkFkb2JlX2NteWtjb2xvcl92YXJzIC9fY3VycmVudHJnYmNvbG9yIGdl dCBleGVjDQozDQp7DQoxIHN1YiBuZWcgMyAxIHJvbGwNCn0gcmVwZWF0DQowDQp9IGRlZg0K Y3VycmVudGRpY3QgcmVhZG9ubHkgcG9wIGVuZA0Kc2V0cGFja2luZw0KDQolJUVuZFJlc291 cmNlDQoNCiUlQmVnaW5SZXNvdXJjZTogcHJvY3NldCBBZG9iZV9jc2hvdyAxLjEgMA0KJSVU aXRsZTogKGNzaG93IE9wZXJhdG9yKQ0KJSVWZXJzaW9uOiAxLjEgDQolJUNyZWF0aW9uRGF0 ZTogKDEvMjMvODkpICgpDQolJUNvcHlyaWdodDogKChDKSAxOTg3LTE5OTAgQWRvYmUgU3lz dGVtcyBJbmNvcnBvcmF0ZWQgQWxsIFJpZ2h0cyBSZXNlcnZlZCkNCmN1cnJlbnRwYWNraW5n IHRydWUgc2V0cGFja2luZw0KdXNlcmRpY3QgL0Fkb2JlX2NzaG93IDMgZGljdCBkdXAgYmVn aW4gcHV0DQovaW5pdGlhbGl6ZQ0Kew0KL2NzaG93IHdoZXJlDQp7DQpwb3ANCn0NCnsNCnVz ZXJkaWN0IC9BZG9iZV9jc2hvd192YXJzIDEgZGljdCBkdXAgYmVnaW4gcHV0DQovX2NzaG93 IA0Ke30gZGVmDQpBZG9iZV9jc2hvdyBiZWdpbg0KQWRvYmVfY3Nob3cNCnsNCmR1cCB4Y2hl Y2sNCnsNCmJpbmQNCn0gaWYNCnVzZXJkaWN0IDMgMSByb2xsIHB1dA0KfSBmb3JhbGwNCmVu ZA0KZW5kDQp9IGlmZWxzZQ0KfSBkZWYNCi90ZXJtaW5hdGUNCnsNCn0gZGVmDQovY3Nob3cN CnsNCmV4Y2gNCkFkb2JlX2NzaG93X3ZhcnMNCmV4Y2ggL19jc2hvdw0KZXhjaCBwdXQNCnsN CjAgMCBBZG9iZV9jc2hvd192YXJzIC9fY3Nob3cgZ2V0IGV4ZWMNCn0gZm9yYWxsDQp9IGRl Zg0KY3VycmVudGRpY3QgcmVhZG9ubHkgcG9wIGVuZA0Kc2V0cGFja2luZw0NCgolJUVuZFJl c291cmNlDQoNCiUlQmVnaW5SZXNvdXJjZTogcHJvY3NldCBBZG9iZV9jdXN0b21jb2xvciAx LjAgMA0KJSVUaXRsZTogKEN1c3RvbSBDb2xvciBPcGVyYXRvcnMpDQolJVZlcnNpb246IDEu MCANCiUlQ3JlYXRpb25EYXRlOiAoNS85Lzg4KSAoKQ0KJSVDb3B5cmlnaHQ6ICgoQykgMTk4 Ny0xOTkwIEFkb2JlIFN5c3RlbXMgSW5jb3Jwb3JhdGVkIEFsbCBSaWdodHMgUmVzZXJ2ZWQp DQpjdXJyZW50cGFja2luZyB0cnVlIHNldHBhY2tpbmcNCnVzZXJkaWN0IC9BZG9iZV9jdXN0 b21jb2xvciA1IGRpY3QgZHVwIGJlZ2luIHB1dA0KL2luaXRpYWxpemUNCnsNCi9zZXRjdXN0 b21jb2xvciB3aGVyZQ0Kew0KcG9wDQp9DQp7DQpBZG9iZV9jdXN0b21jb2xvciBiZWdpbg0K QWRvYmVfY3VzdG9tY29sb3INCnsNCmR1cCB4Y2hlY2sNCnsNCmJpbmQNCn0gaWYNCnBvcCBw b3ANCn0gZm9yYWxsDQplbmQNCkFkb2JlX2N1c3RvbWNvbG9yIGJlZ2luDQp9IGlmZWxzZQ0K fSBkZWYNCi90ZXJtaW5hdGUNCnsNCmN1cnJlbnRkaWN0IEFkb2JlX2N1c3RvbWNvbG9yIGVx DQp7DQplbmQNCn0gaWYNCn0gZGVmDQovZmluZGNteWtjdXN0b21jb2xvcg0Kew0KNSBwYWNr ZWRhcnJheQ0KfSAgZGVmDQovc2V0Y3VzdG9tY29sb3INCnsNCmV4Y2gNCmFsb2FkIHBvcCBw b3ANCjQNCnsNCjQgaW5kZXggbXVsIDQgMSByb2xsDQp9IHJlcGVhdA0KNSAtMSByb2xsIHBv cA0Kc2V0Y215a2NvbG9yDQp9IGRlZg0KL3NldG92ZXJwcmludA0Kew0KcG9wDQp9IGRlZg0K Y3VycmVudGRpY3QgcmVhZG9ubHkgcG9wIGVuZA0Kc2V0cGFja2luZw0KJSVFbmRSZXNvdXJj ZSANDQoKDQolJUJlZ2luUmVzb3VyY2U6IHByb2NzZXQgQWRvYmVfdHlwb2dyYXBoeV9BSTMg MS4wIDANCiUlVGl0bGU6IChUeXBvZ3JhcGh5IE9wZXJhdG9ycyklJVZlcnNpb246IDEuMA0K JSVDcmVhdGlvbkRhdGU6KDUvMzEvOTApICgpDQolJUNvcHlyaWdodDogKChDKSAxOTg3LTE5 OTAgQWRvYmUgU3lzdGVtcyBJbmNvcnBvcmF0ZWQgQWxsIFJpZ2h0cyBSZXNlcnZlZCkNCmN1 cnJlbnRwYWNraW5nIHRydWUgc2V0cGFja2luZw0KdXNlcmRpY3QgL0Fkb2JlX3R5cG9ncmFw aHlfQUkzIDQ2IGRpY3QgZHVwIGJlZ2luIHB1dA0KL2luaXRpYWxpemUNCnsNCi9UWg0Kd2hl cmUNCnsNCnBvcA0KfQ0Kew0KQWRvYmVfdHlwb2dyYXBoeV9BSTMgYmVnaW4NCkFkb2JlX3R5 cG9ncmFwaHlfQUkzDQp7DQpkdXAgeGNoZWNrDQp7DQpiaW5kDQp9IGlmDQpwb3AgcG9wDQp9 IGZvcmFsbA0KZW5kDQpBZG9iZV90eXBvZ3JhcGh5X0FJMyBiZWdpbg0KfSBpZmVsc2UNCn0g ZGVmDQovdGVybWluYXRlDQp7DQpjdXJyZW50ZGljdCBBZG9iZV90eXBvZ3JhcGh5X0FJMyBl cQ0Kew0KZW5kDQp9IGlmDQp9IGRlZg0KL21vZGlmeUVuY29kaW5nDQp7DQovX3RlbXBFbmNv ZGUgZXhjaCBkZGVmDQovX3BudHIgMCBkZGVmDQp7DQpjb3VudHRvbWFyayAtMSByb2xsDQpk dXAgdHlwZSBkdXAgL21hcmt0eXBlIGVxICAgDQp7DQpwb3AgcG9wIGV4aXQNCn0NCnsNCi9u YW1ldHlwZSBlcQ0Kew0KX3RlbXBFbmNvZGUgL19wbnRyIGR1cCBsb2FkIGR1cCAzIDEgcm9s bCAxIGFkZCBkZGVmIDMgLTEgcm9sbA0KcHV0DQp9DQp7DQovX3BudHIgZXhjaCBkZGVmDQp9 DQppZmVsc2UNCn0NCmlmZWxzZQ0KfQ0KbG9vcCANCl90ZW1wRW5jb2RlDQp9DQpkZWYNCi9U RSANCnsNClN0YW5kYXJkRW5jb2RpbmcgMjU2IGFycmF5IGNvcHkgbW9kaWZ5RW5jb2Rpbmcg DQovX25hdGl2ZUVuY29kaW5nIGV4Y2ggZGVmDQp9IGRlZg0KL1RaICANCnsNCi9fdXNlTmF0 aXZlRW5jb2RpbmcgZXhjaCBkZWYNCnBvcCBwb3ANCmZpbmRmb250IGR1cCBsZW5ndGggMiBh ZGQgZGljdA0KYmVnaW4NCm1hcmsgZXhjaA0Kew0KMSBpbmRleCAvRklEIG5lIHsgZGVmIH0g aWYgY2xlYXJ0b21hcmsgbWFyaw0KfQ0KZm9yYWxsDQpwb3ANCi9Gb250TmFtZSBleGNoIGRl Zg0KY291bnR0b21hcmsgMCBlcQ0Kew0KRW5jb2RpbmcgU3RhbmRhcmRFbmNvZGluZyBlcSAx IF91c2VOYXRpdmVFbmNvZGluZyBlcSBhbmQNCnsNCi9FbmNvZGluZyBfbmF0aXZlRW5jb2Rp bmcgZGVmDQp9DQppZg0KY2xlYXJ0b21hcmsNCn0NCnsgDQovRW5jb2RpbmcgbG9hZCAyNTYg YXJyYXkgY29weSANCm1vZGlmeUVuY29kaW5nIC9FbmNvZGluZyBleGNoIGRlZg0KfQ0KaWZl bHNlICANCkZvbnROYW1lIGN1cnJlbnRkaWN0DQplbmQNCmRlZmluZWZvbnQgcG9wDQp9DQpk ZWYNCi90cg0Kew0KX2F4IF9heSAzIDIgcm9sbA0KfSBkZWYNCi90cmogDQp7DQpfY3ggX2N5 IF9zcCBfYXggX2F5IDYgNSByb2xsDQp9IGRlZg0NCgovYTANCnsNCi9UeCANCnsNCmR1cCAN CmN1cnJlbnRwb2ludCAzIDIgcm9sbA0KdHIgX3BzZg0KbmV3cGF0aCBtb3ZldG8NCnRyIF9j dG0gX3Bzcw0KfSBkZGVmDQovVGogDQp7DQpkdXANCmN1cnJlbnRwb2ludCAzIDIgcm9sbA0K dHJqIF9wanNmDQpuZXdwYXRoIG1vdmV0bw0KdHJqIF9jdG0gX3Bqc3MNCn0gZGRlZg0KfSBk ZWYNCi9hMQ0Kew0KVyBCDQp9IGRlZg0KL2UwDQp7DQovVHggDQp7DQp0ciBfcHNmDQp9IGRk ZWYNCi9UaiANCnsNCnRyaiBfcGpzZg0KfSBkZGVmDQp9IGRlZg0KL2UxDQp7DQpXIEYgDQp9 IGRlZg0KL2kwDQp7DQovVHgNCnsNCnRyIHNwDQp9IGRkZWYNCi9Uag0Kew0KdHJqIGpzcA0K fSBkZGVmDQp9IGRlZg0KL28wDQp7DQovVHgNCnsNCnRyIHN3IHJtb3ZldG8NCn0gZGRlZg0K L1RqDQp7DQp0cmogc3dqIHJtb3ZldG8NCn0gZGRlZg0KfSBkZWYNCi9yMA0Kew0KL1R4DQp7 DQp0ciBfY3RtIF9wc3MNCn0gZGRlZg0KL1RqDQp7DQp0cmogX2N0bSBfcGpzcw0KfSBkZGVm DQp9IGRlZg0KL3IxDQp7DQpXIFMNCn0gZGVmDQovVG8NCnsNCnBvcCBfY3RtIGN1cnJlbnRt YXRyaXggcG9wDQp9IGRlZg0KL1RPDQp7DQpUZSBfY3RtIHNldG1hdHJpeCBuZXdwYXRoDQp9 IGRlZg0KL1RwDQp7DQpwb3AgX3RtIGFzdG9yZSBwb3AgX2N0bSBzZXRtYXRyaXggDQoyIGRp Y3QgYmVnaW4gL1cge30gZGVmIC9oIHt9IGRlZg0KfSBkZWYNCi9UUA0Kew0KZW5kDQppVG0g MCAwIG1vdmV0bw0KfSBkZWYNCi9Ucg0Kew0KVGUgY3VycmVudHBvaW50IG5ld3BhdGggbW92 ZXRvDQpkdXAgOCBlcSB7cG9wIDB9IHtkdXAgOSBlcSB7cG9wIDF9IGlmfSBpZmVsc2UNCmR1 cCAvX3JlbmRlciBleGNoIGRkZWYNCl9yZW5kZXJTdGFydCBleGNoIGdldCBsb2FkIGV4ZWMN Cn0gZGVmDQovaVRtIA0Kew0KX2N0bSBzZXRtYXRyaXggX3RtIGNvbmNhdCAwIF9yaXNlIHRy YW5zbGF0ZSBfaHMgMSBzY2FsZQ0KfSBkZWYNCi9UZQ0Kew0KX3JlbmRlciAtMSBlcSB7fSB7 X3JlbmRlckVuZCBfcmVuZGVyIGdldCBkdXAgbnVsbCBuZSB7bG9hZCBleGVjfSB7cG9wfSBp ZmVsc2V9IGlmZWxzZQ0KL19yZW5kZXIgLTEgZGRlZg0KfSBkZWYNCi9UZg0Kew0KZHVwIDEw MDAgZGl2IC9fZlNjbCBleGNoIGRkZWYNCmV4Y2ggZmluZGZvbnQgZXhjaCBzY2FsZWZvbnQg c2V0Zm9udA0KfSBkZWYNCi9UbA0Kew0KcG9wDQowIGV4Y2ggX2xlYWRpbmcgYXN0b3JlIHBv cA0KfSBkZWYNCi9UdCANCnsNCnBvcA0KfSBkZWYNCi9UVw0Kew0KMyBucG9wDQp9IGRlZg0K L1R3DQp7DQovX2N4IGV4Y2ggZGRlZg0KfSBkZWYNCi9UYw0Kew0KL19heCBleGNoIGRkZWYN Cn0gZGVmDQovVHMNCnsNCi9fcmlzZSBleGNoIGRkZWYNCmN1cnJlbnRwb2ludA0KaVRtDQpt b3ZldG8NCn0gZGVmDQovVGkNCnsNCjMgbnBvcA0KfSBkZWYNCi9Ueg0Kew0KMTAwIGRpdiAv X2hzIGV4Y2ggZGRlZg0KaVRtDQp9IGRlZg0KL1RxIA0Kew0KcG9wDQp9IGRlZg0KL1RYIHtw b3B9IGRlZg0KL1RrDQp7DQpleGNoIHBvcCBfZlNjbCBtdWwgbmVnIDAgcm1vdmV0bw0KfSBk ZWYNCi9ULSANCnsNCl9oeXBoZW4gVHgNCn0gZGVmDQovVFMNCnsNCjAgZXEge1R4fSB7VGp9 IGlmZWxzZQ0KfSBkZWYNCmN1cnJlbnRkaWN0IHJlYWRvbmx5IHBvcCBlbmQNCnNldHBhY2tp bmcNCiUlRW5kUmVzb3VyY2UNCg0KJSVCZWdpblJlc291cmNlOiBwcm9jc2V0IEFkb2JlX0ls bHVzdHJhdG9yX0FJMyAxLjAgMA0KJSVUaXRsZTogKEFkb2JlIElsbHVzdHJhdG9yIChSKSBW ZXJzaW9uIDMuMCBGdWxsIFByb2xvZykNCiUlVmVyc2lvbjogMS4wIA0KJSVDcmVhdGlvbkRh dGU6ICg3LzIyLzg5KSAoKQ0KJSVDb3B5cmlnaHQ6ICgoQykgMTk4Ny0xOTkwIEFkb2JlIFN5 c3RlbXMgSW5jb3Jwb3JhdGVkIEFsbCBSaWdodHMgUmVzZXJ2ZWQpDQpjdXJyZW50cGFja2lu ZyB0cnVlIHNldHBhY2tpbmcNCnVzZXJkaWN0IC9BZG9iZV9JbGx1c3RyYXRvcl9BSTMgNzEg ZGljdCBkdXAgYmVnaW4gcHV0DQovaW5pdGlhbGl6ZQ0Kew0KdXNlcmRpY3QgL0Fkb2JlX0ls bHVzdHJhdG9yX0FJM192YXJzIDU1IGRpY3QgZHVwIGJlZ2luIHB1dA0KL19scCAvbm9uZSBk ZWYNCi9fcGYge30gZGVmDQovX3BzIHt9IGRlZg0KL19wc2Yge30gZGVmDQovX3BzcyB7fSBk ZWYNCi9fcGpzZiB7fSBkZWYNCi9fcGpzcyB7fSBkZWYNCi9fcG9sYSAwIGRlZg0KL19kb0Ns aXAgMCBkZWYNCi9jZiBjdXJyZW50ZmxhdCBkZWYNCi9fdG0gbWF0cml4IGRlZg0KL19yZW5k ZXJTdGFydCBbL2UwIC9yMCAvYTAgL28wIC9pMCAvaTAgL2kwIC9pMF0gZGVmIA0KL19yZW5k ZXJFbmQgW251bGwgbnVsbCBudWxsIG51bGwgL2UxIC9yMSAvYTEgL2NsaXBdIGRlZg0KL19y ZW5kZXIgLTEgZGVmDQovX3Jpc2UgMCBkZWYNCi9fYXggMCBkZWYNCi9fYXkgMCBkZWYNCi9f Y3ggMCBkZWYNCi9fY3kgMCBkZWYNCi9fbGVhZGluZyBbMCAwXSBkZWYNCi9fY3RtIG1hdHJp eCBkZWYNCi9fbXR4IG1hdHJpeCBkZWYNCi9fc3AgMTYjMDIwIGRlZg0KL19oeXBoZW4gKC0p IGRlZg0KL19mU2NsIDAgZGVmDQovX2NudCAwIGRlZg0KL19ocyAxIGRlZg0KL19uYXRpdmVF bmNvZGluZyAwIGRlZg0KL191c2VOYXRpdmVFbmNvZGluZyAwIGRlZg0KL190ZW1wRW5jb2Rl IDAgZGVmDQovX3BudHIgMCBkZWYNCi9UeCB7fSBkZWYNCi9UaiB7fSBkZWYNCi9DUmVuZGVy IHt9IGRlZg0KL19BSTNfc2F2ZXBhZ2Uge30gZGVmDQovX2dmIG51bGwgZGVmDQovX2NmIDQg YXJyYXkgZGVmDQovX2lmIG51bGwgZGVmDQovX29mIGZhbHNlIGRlZg0KL19mYyB7fSBkZWYN Ci9fZ3MgbnVsbCBkZWYNCi9fY3MgNCBhcnJheSBkZWYNCi9faXMgbnVsbCBkZWYNCi9fb3Mg ZmFsc2UgZGVmDQovX3NjIHt9IGRlZg0KL19wZCAxIGRpY3QgZGVmDQovX2VkIDE1IGRpY3Qg ZGVmDQovX3BtIG1hdHJpeCBkZWYNCi9fZm0gbnVsbCBkZWYNCi9fZmQgbnVsbCBkZWYNCi9f ZmRkIG51bGwgZGVmDQovX3NtIG51bGwgZGVmDQovX3NkIG51bGwgZGVmDQovX3NkZCBudWxs IGRlZg0KL19pIG51bGwgZGVmDQpBZG9iZV9JbGx1c3RyYXRvcl9BSTMgYmVnaW4NCkFkb2Jl X0lsbHVzdHJhdG9yX0FJMyBkdXAgL25jIGdldCBiZWdpbg0Kew0KZHVwIHhjaGVjaw0Kew0K YmluZA0KfSBpZg0KcG9wIHBvcA0KfSBmb3JhbGwNCmVuZA0KZW5kDQplbmQNCkFkb2JlX0ls bHVzdHJhdG9yX0FJMyBiZWdpbg0KQWRvYmVfSWxsdXN0cmF0b3JfQUkzX3ZhcnMgYmVnaW4N Cm5ld3BhdGgNCn0gZGVmDQovdGVybWluYXRlDQp7DQplbmQNCmVuZA0KfSBkZWYNDQoKL18N Cm51bGwgZGVmDQovZGRlZg0Kew0KQWRvYmVfSWxsdXN0cmF0b3JfQUkzX3ZhcnMgMyAxIHJv bGwgcHV0DQp9IGRlZg0KL3hwdXQNCnsNCmR1cCBsb2FkIGR1cCBsZW5ndGggZXhjaCBtYXhs ZW5ndGggZXENCnsNCmR1cCBkdXAgbG9hZCBkdXANCmxlbmd0aCAyIG11bCBkaWN0IGNvcHkg ZGVmDQp9IGlmDQpsb2FkIGJlZ2luIGRlZiBlbmQNCn0gZGVmDQovbnBvcA0Kew0Kew0KcG9w DQp9IHJlcGVhdA0KfSBkZWYNDQoKL3N3DQp7DQpkdXAgbGVuZ3RoIGV4Y2ggc3RyaW5nd2lk dGgNCmV4Y2ggNSAtMSByb2xsIDMgaW5kZXggMSBzdWIgbXVsIGFkZA0KNCAxIHJvbGwgMyAx IHJvbGwgMSBzdWIgbXVsIGFkZA0KfSBkZWYNCi9zd2oNCnsNCmR1cCA0IDEgcm9sbA0KZHVw IGxlbmd0aCBleGNoIHN0cmluZ3dpZHRoIA0KZXhjaCA1IC0xIHJvbGwgMyBpbmRleCAxIHN1 YiBtdWwgYWRkDQo0IDEgcm9sbCAzIDEgcm9sbCAxIHN1YiBtdWwgYWRkIA0KNiAyIHJvbGwg L19jbnQgMCBkZGVmDQp7MSBpbmRleCBlcSB7L19jbnQgX2NudCAxIGFkZCBkZGVmfSBpZn0g Zm9yYWxsIHBvcA0KZXhjaCBfY250IG11bCBleGNoIF9jbnQgbXVsIDIgaW5kZXggYWRkIDQg MSByb2xsIDIgaW5kZXggYWRkIDQgMSByb2xsIHBvcCBwb3ANCn0gZGVmDQovc3MNCnsNCjQg MSByb2xsDQp7DQoyIG5wb3AgDQooMCkgZXhjaCAyIGNvcHkgMCBleGNoIHB1dCBwb3ANCmdz YXZlDQpmYWxzZSBjaGFycGF0aCBjdXJyZW50cG9pbnQNCjQgaW5kZXggc2V0bWF0cml4DQpz dHJva2UNCmdyZXN0b3JlDQptb3ZldG8NCjIgY29weSBybW92ZXRvDQp9IGV4Y2ggY3Nob3cN CjMgbnBvcA0KfSBkZWYNCi9qc3MNCnsNCjQgMSByb2xsDQp7DQoyIG5wb3AgDQooMCkgZXhj aCAyIGNvcHkgMCBleGNoIHB1dCANCmdzYXZlDQpfc3AgZXEgDQp7DQpleGNoIDYgaW5kZXgg NiBpbmRleCA2IGluZGV4IDUgLTEgcm9sbCB3aWR0aHNob3cgIA0KY3VycmVudHBvaW50DQp9 DQp7DQpmYWxzZSBjaGFycGF0aCBjdXJyZW50cG9pbnQNCjQgaW5kZXggc2V0bWF0cml4IHN0 cm9rZQ0KfWlmZWxzZQ0KZ3Jlc3RvcmUNCm1vdmV0bw0KMiBjb3B5IHJtb3ZldG8NCn0gZXhj aCBjc2hvdw0KNiBucG9wDQp9IGRlZg0KL3NwDQp7DQp7DQoyIG5wb3AgKDApIGV4Y2gNCjIg Y29weSAwIGV4Y2ggcHV0IHBvcA0KZmFsc2UgY2hhcnBhdGgNCjIgY29weSBybW92ZXRvDQp9 IGV4Y2ggY3Nob3cNCjIgbnBvcA0KfSBkZWYNCi9qc3ANCnsNCnsNCjIgbnBvcCANCigwKSBl eGNoIDIgY29weSAwIGV4Y2ggcHV0IA0KX3NwIGVxIA0Kew0KZXhjaCA1IGluZGV4IDUgaW5k ZXggNSBpbmRleCA1IC0xIHJvbGwgd2lkdGhzaG93ICANCn0NCnsNCmZhbHNlIGNoYXJwYXRo DQp9aWZlbHNlDQoyIGNvcHkgcm1vdmV0bw0KfSBleGNoIGNzaG93DQo1IG5wb3ANCn0gZGVm DQovcGwNCnsNCnRyYW5zZm9ybQ0KMC4yNSBzdWIgcm91bmQgMC4yNSBhZGQgZXhjaA0KMC4y NSBzdWIgcm91bmQgMC4yNSBhZGQgZXhjaA0KaXRyYW5zZm9ybQ0KfSBkZWYNCi9zZXRzdHJv a2VhZGp1c3Qgd2hlcmUNCntwb3AgdHJ1ZSBzZXRzdHJva2VhZGp1c3QNCi9jDQp7DQpjdXJ2 ZXRvDQp9IGRlZg0KL0MNCi9jIGxvYWQgZGVmDQovdg0Kew0KY3VycmVudHBvaW50IDYgMiBy b2xsIGN1cnZldG8NCn0gZGVmDQovVg0KL3YgbG9hZCBkZWYNCi95DQp7DQoyIGNvcHkgY3Vy dmV0bw0KfSBkZWYNCi9ZDQoveSBsb2FkIGRlZg0KL2wNCnsNCmxpbmV0bw0KfSBkZWYNCi9M DQovbCBsb2FkIGRlZg0KL20NCnsNCm1vdmV0bw0KfSBkZWYNCn0NCnsNCi9jDQp7DQpwbCBj dXJ2ZXRvDQp9IGRlZg0KL0MNCi9jIGxvYWQgZGVmDQovdg0Kew0KY3VycmVudHBvaW50IDYg MiByb2xsIHBsIGN1cnZldG8NCn0gZGVmDQovVg0KL3YgbG9hZCBkZWYNCi95DQp7DQpwbCAy IGNvcHkgY3VydmV0bw0KfSBkZWYNCi9ZDQoveSBsb2FkIGRlZg0KL2wNCnsNCnBsIGxpbmV0 bw0KfSBkZWYNCi9MDQovbCBsb2FkIGRlZg0KL20NCnsNCnBsIG1vdmV0bw0KfSBkZWYNCn0g aWZlbHNlDQovZA0Kew0Kc2V0ZGFzaA0KfSBkZWYNCi9jZiB7fSBkZWYNCi9pDQp7DQpkdXAg MCBlcQ0Kew0KcG9wIGNmDQp9IGlmDQpzZXRmbGF0DQp9IGRlZg0KL2oNCnsNCnNldGxpbmVq b2luDQp9IGRlZg0KL0oNCnsNCnNldGxpbmVjYXANCn0gZGVmDQovTQ0Kew0Kc2V0bWl0ZXJs aW1pdA0KfSBkZWYNCi93DQp7DQpzZXRsaW5ld2lkdGgNCn0gZGVmDQovSCB7fSBkZWYgL2gg eyBjbG9zZXBhdGggfSBkZWYgL04geyBfcG9sYSAwIGVxIHsNCg0KX2RvQ2xpcCAxIGVxIHtj bGlwIC9fZG9DbGlwIDAgZGRlZn0gaWYgbmV3cGF0aCB9IHsNCg0KL0NSZW5kZXIge059IGRk ZWYgfWlmZWxzZSB9IGRlZiAvbiB7Tn0gZGVmDQoNCi9GDQp7DQpfcG9sYSAwIGVxIA0Kew0K X2RvQ2xpcCAxIGVxIA0Kew0KZ3NhdmUgX3BmIGdyZXN0b3JlIGNsaXAgbmV3cGF0aCAvX2xw IC9ub25lIGRkZWYgX2ZjIA0KL19kb0NsaXAgMCBkZGVmDQp9DQp7DQpfcGYNCn1pZmVsc2UN Cn0gDQp7DQovQ1JlbmRlciB7Rn0gZGRlZg0KfWlmZWxzZQ0KfSBkZWYNCi9mDQp7DQpjbG9z ZXBhdGgNCkYNCn0gZGVmDQovUw0Kew0KX3BvbGEgMCBlcSANCnsNCl9kb0NsaXAgMSBlcSAN CnsNCmdzYXZlIF9wcyBncmVzdG9yZSBjbGlwIG5ld3BhdGggL19scCAvbm9uZSBkZGVmIF9z YyANCi9fZG9DbGlwIDAgZGRlZg0KfQ0Kew0KX3BzDQp9aWZlbHNlDQp9IA0Kew0KL0NSZW5k ZXIge1N9IGRkZWYNCn1pZmVsc2UNCn0gZGVmDQovcw0Kew0KY2xvc2VwYXRoDQpTDQp9IGRl Zg0KL0INCnsNCl9wb2xhIDAgZXEgDQp7DQpfZG9DbGlwIDEgZXENCmdzYXZlIEYgZ3Jlc3Rv cmUgDQp7DQpnc2F2ZSBTIGdyZXN0b3JlIGNsaXAgbmV3cGF0aCAvX2xwIC9ub25lIGRkZWYg X3NjDQovX2RvQ2xpcCAwIGRkZWYNCn0gDQp7DQpTDQp9aWZlbHNlDQp9DQp7DQovQ1JlbmRl ciB7Qn0gZGRlZg0KfWlmZWxzZQ0KfSBkZWYNCi9iDQp7DQpjbG9zZXBhdGgNCkINCn0gZGVm DQovVw0Kew0KL19kb0NsaXAgMSBkZGVmDQp9IGRlZg0KLyoNCnsNCmNvdW50IDAgbmUgDQp7 DQpkdXAgdHlwZSAoc3RyaW5ndHlwZSkgZXEge3BvcH0gaWYNCn0gaWYgDQpfcG9sYSAwIGVx IHtuZXdwYXRofSBpZg0KfSBkZWYNCi91DQp7fSBkZWYNCi9VDQp7fSBkZWYNCi9xDQp7X3Bv bGEgMCBlcSB7Z3NhdmV9IGlmDQp9IGRlZg0KL1ENCnsNCl9wb2xhIDAgZXEge2dyZXN0b3Jl fSBpZg0KfSBkZWYNCi8qdQ0Kew0KX3BvbGEgMSBhZGQgL19wb2xhIGV4Y2ggZGRlZg0KfSBk ZWYNCi8qVQ0Kew0KX3BvbGEgMSBzdWIgL19wb2xhIGV4Y2ggZGRlZiANCl9wb2xhIDAgZXEg e0NSZW5kZXJ9IGlmDQp9IGRlZg0KL0QNCntwb3B9IGRlZg0KLyp3DQp7fSBkZWYNCi8qVw0K e30gZGVmDQovYA0Kew0KL19pIHNhdmUgZGRlZg0KNiAxIHJvbGwgNCBucG9wDQpjb25jYXQN CnVzZXJkaWN0IGJlZ2luDQovc2hvd3BhZ2Uge30gZGVmDQpmYWxzZSBzZXRvdmVycHJpbnQN CnBvcA0KfSBkZWYNCi9+IHsgZW5kIF9pIHJlc3RvcmUgfSBkZWYNCi9ADQp7fSBkZWYNCi8m DQp7fSBkZWYNCi9PDQp7DQowIG5lDQovX29mIGV4Y2ggZGRlZg0KL19scCAvbm9uZSBkZGVm DQp9IGRlZg0KL1INCnsNCjAgbmUNCi9fb3MgZXhjaCBkZGVmDQovX2xwIC9ub25lIGRkZWYN Cn0gZGVmDQovZw0Kew0KL19nZiBleGNoIGRkZWYNCi9fZmMNCnsNCl9scCAvZmlsbCBuZQ0K ew0KX29mIHNldG92ZXJwcmludA0KX2dmIHNldGdyYXkNCi9fbHAgL2ZpbGwgZGRlZg0KfSBp Zg0KfSBkZGVmDQovX3BmDQp7DQpfZmMNCmZpbGwNCn0gZGRlZg0KL19wc2YNCnsNCl9mYw0K YXNob3cNCn0gZGRlZg0KL19wanNmDQp7DQpfZmMNCmF3aWR0aHNob3cNCn0gZGRlZg0KL19s cCAvbm9uZSBkZGVmDQp9IGRlZg0KL0cNCnsNCi9fZ3MgZXhjaCBkZGVmDQovX3NjDQp7DQpf bHAgL3N0cm9rZSBuZQ0Kew0KX29zIHNldG92ZXJwcmludA0KX2dzIHNldGdyYXkNCi9fbHAg L3N0cm9rZSBkZGVmDQp9IGlmDQp9IGRkZWYNCi9fcHMNCnsNCl9zYw0Kc3Ryb2tlDQp9IGRk ZWYNCi9fcHNzDQp7DQpfc2MNCnNzDQp9IGRkZWYNCi9fcGpzcw0Kew0KX3NjDQpqc3MNCn0g ZGRlZg0KL19scCAvbm9uZSBkZGVmDQp9IGRlZg0KL2sNCnsNCl9jZiBhc3RvcmUgcG9wDQov X2ZjDQp7DQpfbHAgL2ZpbGwgbmUNCnsNCl9vZiBzZXRvdmVycHJpbnQNCl9jZiBhbG9hZCBw b3Agc2V0Y215a2NvbG9yDQovX2xwIC9maWxsIGRkZWYNCn0gaWYNCn0gZGRlZg0KL19wZg0K ew0KX2ZjDQpmaWxsDQp9IGRkZWYNCi9fcHNmDQp7DQpfZmMNCmFzaG93DQp9IGRkZWYNCi9f cGpzZg0Kew0KX2ZjDQphd2lkdGhzaG93DQp9IGRkZWYNCi9fbHAgL25vbmUgZGRlZg0KfSBk ZWYNCi9LDQp7DQpfY3MgYXN0b3JlIHBvcA0KL19zYw0Kew0KX2xwIC9zdHJva2UgbmUNCnsN Cl9vcyBzZXRvdmVycHJpbnQNCl9jcyBhbG9hZCBwb3Agc2V0Y215a2NvbG9yDQovX2xwIC9z dHJva2UgZGRlZg0KfSBpZg0KfSBkZGVmDQovX3BzDQp7DQpfc2MNCnN0cm9rZQ0KfSBkZGVm DQovX3Bzcw0Kew0KX3NjDQpzcw0KfSBkZGVmDQovX3Bqc3MNCnsNCl9zYw0KanNzDQp9IGRk ZWYNCi9fbHAgL25vbmUgZGRlZg0KfSBkZWYNCi94DQp7DQovX2dmIGV4Y2ggZGRlZg0KZmlu ZGNteWtjdXN0b21jb2xvcg0KL19pZiBleGNoIGRkZWYNCi9fZmMNCnsNCl9scCAvZmlsbCBu ZQ0Kew0KX29mIHNldG92ZXJwcmludA0KX2lmIF9nZiAxIGV4Y2ggc3ViIHNldGN1c3RvbWNv bG9yDQovX2xwIC9maWxsIGRkZWYNCn0gaWYNCn0gZGRlZg0KL19wZg0Kew0KX2ZjDQpmaWxs DQp9IGRkZWYNCi9fcHNmDQp7DQpfZmMNCmFzaG93DQp9IGRkZWYNCi9fcGpzZg0Kew0KX2Zj DQphd2lkdGhzaG93DQp9IGRkZWYNCi9fbHAgL25vbmUgZGRlZg0KfSBkZWYNCi9YDQp7DQov X2dzIGV4Y2ggZGRlZg0KZmluZGNteWtjdXN0b21jb2xvcg0KL19pcyBleGNoIGRkZWYNCi9f c2MNCnsNCl9scCAvc3Ryb2tlIG5lDQp7DQpfb3Mgc2V0b3ZlcnByaW50DQpfaXMgX2dzIDEg ZXhjaCBzdWIgc2V0Y3VzdG9tY29sb3INCi9fbHAgL3N0cm9rZSBkZGVmDQp9IGlmDQp9IGRk ZWYNCi9fcHMNCnsNCl9zYw0Kc3Ryb2tlDQp9IGRkZWYNCi9fcHNzDQp7DQpfc2MNCnNzDQp9 IGRkZWYNCi9fcGpzcw0Kew0KX3NjDQpqc3MNCn0gZGRlZg0KL19scCAvbm9uZSBkZGVmDQp9 IGRlZg0KL2RwDQp7DQpkdXAgbnVsbCBlcQ0Kew0KcG9wDQpfZHAgMCBuZQ0Kew0KMCAxIF9k cCAxIHN1YiBfZGwgbW9kDQp7DQpfZGEgZXhjaCBnZXQgMyBnZXQNCn0gZm9yDQpfZHAgMSBz dWIgX2RsIG1vZCAxIGFkZCBwYWNrZWRhcnJheQ0KX2RhIDAgZ2V0IGFsb2FkIHBvcCA4IC0x IHJvbGwgNSAtMSByb2xsIHBvcCA0IDEgcm9sbA0KZGVmaW5lcGF0dGVybiBwb3ANCn0gaWYN Cn0NCnsNCl9kcCAwIG5lIF9kcCBfZGwgbW9kIDAgZXEgYW5kDQp7DQpudWxsIGRwDQp9IGlm DQo3IHBhY2tlZGFycmF5IF9kYSBleGNoIF9kcCBfZGwgbW9kIGV4Y2ggcHV0DQpfZHAgX2Rs IG1vZCBfZGEgMCBnZXQgNCBnZXQgMiBwYWNrZWRhcnJheQ0KL19kcCBfZHAgMSBhZGQgZGVm DQp9IGlmZWxzZQ0KfSBkZWYNCi9FDQp7DQpfZWQgYmVnaW4NCmR1cCAwIGdldCB0eXBlIC9h cnJheXR5cGUgbmUNCnsNCjANCnsNCmR1cCAxIGFkZCBpbmRleCB0eXBlIC9hcnJheXR5cGUg ZXENCnsNCjEgYWRkDQp9DQp7DQpleGl0DQp9IGlmZWxzZQ0KfSBsb29wDQphcnJheSBhc3Rv cmUNCn0gaWYNCi9fZGQgZXhjaCBkZWYNCi9fdXJ5IGV4Y2ggZGVmDQovX3VyeCBleGNoIGRl Zg0KL19sbHkgZXhjaCBkZWYNCi9fbGx4IGV4Y2ggZGVmDQovX24gZXhjaCBkZWYNCi9feSAw IGRlZg0KL19kbCA0IGRlZg0KL19kcCAwIGRlZg0KL19kYSBfZGwgYXJyYXkgZGVmDQowIDEg X2RkIGxlbmd0aCAxIHN1Yg0Kew0KL19kIGV4Y2ggX2RkIGV4Y2ggZ2V0IGRlZg0KMCAyIF9k IGxlbmd0aCAyIHN1Yg0Kew0KL194IGV4Y2ggZGVmDQovX2MgX2QgX3ggZ2V0IF8gbmUgZGVm DQovX3IgX2QgX3ggMSBhZGQgZ2V0IGN2bGl0IGRlZg0KX3IgXyBuZQ0Kew0KX3VyeCBfbGx4 IHN1YiBfdXJ5IF9sbHkgc3ViIFsxIDAgMCAxIDAgMF0gDQpbDQovc2F2ZSBjdngNCl9sbHgg bmVnIF9sbHkgbmVnIC90cmFuc2xhdGUgY3Z4DQpfYw0Kew0KbmMgL2JlZ2luIGN2eA0KfSBp Zg0KX3IgZHVwIHR5cGUgL3N0cmluZ3R5cGUgZXENCnsNCmN2eA0KfQ0Kew0Ke2V4ZWN9IC9m b3JhbGwgY3Z4DQp9IGlmZWxzZQ0KX2MNCnsNCi9lbmQgY3Z4DQp9IGlmDQovcmVzdG9yZSBj dngNCl0gY3Z4DQovX2ZuIDEyIF9uIGxlbmd0aCBhZGQgc3RyaW5nIGRlZg0KX3kgX2ZuIGN2 cyBwb3ANCi9feSBfeSAxIGFkZCBkZWYNCl9mbiAxMiBfbiBwdXRpbnRlcnZhbA0KX2ZuIF9j IGZhbHNlIGRwDQpfZCBleGNoIF94IDEgYWRkIGV4Y2ggcHV0DQp9IGlmDQp9IGZvcg0KfSBm b3INCm51bGwgZHANCl9uIF9kZCAvX3BkDQplbmQgeHB1dA0KfSBkZWYNCi9mYw0Kew0KX2Zt IGR1cCBjb25jYXRtYXRyaXggcG9wDQp9IGRlZg0KL3ANCnsNCi9fZm0gZXhjaCBkZGVmDQo5 IC0yIHJvbGwgX3BtIHRyYW5zbGF0ZSBmYw0KNyAtMiByb2xsIF9wbSBzY2FsZSBmYw0KNSAt MSByb2xsIF9wbSByb3RhdGUgZmMNCjQgLTIgcm9sbCBleGNoIDAgbmUNCnsNCmR1cCBfcG0g cm90YXRlIGZjDQoxIC0xIF9wbSBzY2FsZSBmYw0KbmVnIF9wbSByb3RhdGUgZmMNCn0NCnsN CnBvcA0KfSBpZmVsc2UNCmR1cCBfcG0gcm90YXRlIGZjDQpleGNoIGR1cCBzaW4gZXhjaCBj b3MgZGl2IDEgMCAwIDEgMCA2IDIgcm9sbA0KX3BtIGFzdG9yZSBmYw0KbmVnIF9wbSByb3Rh dGUgZmMNCl9wZCBleGNoIGdldCAvX2ZkZCBleGNoIGRkZWYNCi9fcGYNCnsNCnNhdmUNCjAg MSBfZmRkIGxlbmd0aCAxIHN1Yg0Kew0KL19mZCBleGNoIF9mZGQgZXhjaCBnZXQgZGRlZg0K X2ZkDQowIDIgX2ZkIGxlbmd0aCAyIHN1Yg0Kew0KZ3NhdmUNCjIgY29weSBnZXQgZHVwIF8g bmUNCnsNCmN2eCBleGVjIF9mYw0KfQ0Kew0KcG9wDQp9IGlmZWxzZQ0KMiBjb3B5IDEgYWRk IGdldCBkdXAgXyBuZQ0Kew0KYWxvYWQgcG9wIGZpbmRmb250IF9mbQ0KcGF0dGVybmZpbGwN Cn0NCnsNCnBvcA0KZmlsbA0KfSBpZmVsc2UNCmdyZXN0b3JlDQpwb3ANCn0gZm9yDQpwb3AN Cn0gZm9yDQpyZXN0b3JlDQpuZXdwYXRoDQp9IGRkZWYNCi9fcHNmDQp7DQpzYXZlDQowIDEg X2ZkZCBsZW5ndGggMSBzdWINCnsNCi9fZmQgZXhjaCBfZmRkIGV4Y2ggZ2V0IGRkZWYNCl9m ZA0KMCAyIF9mZCBsZW5ndGggMiBzdWINCnsNCmdzYXZlDQoyIGNvcHkgZ2V0IGR1cCBfIG5l DQp7DQpjdnggZXhlYyBfZmMNCn0NCnsNCnBvcA0KfSBpZmVsc2UNCjIgY29weSAxIGFkZCBn ZXQgZHVwIF8gbmUNCnsNCmFsb2FkIHBvcCBmaW5kZm9udCBfZm0NCjkgY29weSA2IG5wb3Ag cGF0dGVybmFzaG93DQp9DQp7DQpwb3ANCjYgY29weSAzIG5wb3AgYXNob3cNCn0gaWZlbHNl DQpncmVzdG9yZQ0KcG9wDQp9IGZvcg0KcG9wDQp9IGZvcg0KcmVzdG9yZQ0KDQpzdyBybW92 ZXRvDQp9IGRkZWYNCi9fcGpzZg0Kew0Kc2F2ZQ0KMCAxIF9mZGQgbGVuZ3RoIDEgc3ViDQp7 DQovX2ZkIGV4Y2ggX2ZkZCBleGNoIGdldCBkZGVmDQpfZmQNCjAgMiBfZmQgbGVuZ3RoIDIg c3ViDQp7DQpnc2F2ZQ0KMiBjb3B5IGdldCBkdXAgXyBuZQ0Kew0KY3Z4IGV4ZWMgX2ZjDQp9 DQp7DQpwb3ANCn0gaWZlbHNlDQoyIGNvcHkgMSBhZGQgZ2V0IGR1cCBfIG5lDQp7DQphbG9h ZCBwb3AgZmluZGZvbnQgX2ZtDQoxMiBjb3B5IDYgbnBvcCBwYXR0ZXJuYXdpZHRoc2hvdw0K fQ0Kew0KcG9wIDkgY29weSAzIG5wb3AgYXdpZHRoc2hvdw0KfSBpZmVsc2UNCmdyZXN0b3Jl DQpwb3ANCn0gZm9yDQpwb3ANCn0gZm9yDQpyZXN0b3JlDQpzd2ogcm1vdmV0bw0KfSBkZGVm DQovX2xwIC9ub25lIGRkZWYNCn0gZGVmDQovc2MNCnsNCl9zbSBkdXAgY29uY2F0bWF0cml4 IHBvcA0KfSBkZWYNCi9QDQp7DQovX3NtIGV4Y2ggZGRlZg0KOSAtMiByb2xsIF9wbSB0cmFu c2xhdGUgc2MNCjcgLTIgcm9sbCBfcG0gc2NhbGUgc2MNCjUgLTEgcm9sbCBfcG0gcm90YXRl IHNjDQo0IC0yIHJvbGwgZXhjaCAwIG5lDQp7DQpkdXAgX3BtIHJvdGF0ZSBzYw0KMSAtMSBf cG0gc2NhbGUgc2MNCm5lZyBfcG0gcm90YXRlIHNjDQp9DQp7DQpwb3ANCn0gaWZlbHNlDQpk dXAgX3BtIHJvdGF0ZSBzYw0KZXhjaCBkdXAgc2luIGV4Y2ggY29zIGRpdiAxIDAgMCAxIDAg NiAyIHJvbGwNCl9wbSBhc3RvcmUgc2MNCm5lZyBfcG0gcm90YXRlIHNjDQpfcGQgZXhjaCBn ZXQgL19zZGQgZXhjaCBkZGVmDQovX3BzDQp7DQpzYXZlDQowIDEgX3NkZCBsZW5ndGggMSBz dWINCnsNCi9fc2QgZXhjaCBfc2RkIGV4Y2ggZ2V0IGRkZWYNCl9zZA0KMCAyIF9zZCBsZW5n dGggMiBzdWINCnsNCmdzYXZlDQoyIGNvcHkgZ2V0IGR1cCBfIG5lDQp7DQpjdnggZXhlYyBf c2MNCn0NCnsNCnBvcA0KfSBpZmVsc2UNCjIgY29weSAxIGFkZCBnZXQgZHVwIF8gbmUNCnsN CmFsb2FkIHBvcCBmaW5kZm9udCBfc20NCnBhdHRlcm5zdHJva2UNCn0NCnsNCnBvcCBzdHJv a2UNCn0gaWZlbHNlDQpncmVzdG9yZQ0KcG9wDQp9IGZvcg0KcG9wDQp9IGZvcg0KcmVzdG9y ZQ0KbmV3cGF0aA0KfSBkZGVmDQovX3Bzcw0Kew0Kc2F2ZQ0KMCAxIF9zZGQgbGVuZ3RoIDEg c3ViDQp7DQovX3NkIGV4Y2ggX3NkZCBleGNoIGdldCBkZGVmDQpfc2QNCjAgMiBfc2QgbGVu Z3RoIDIgc3ViDQp7DQpnc2F2ZQ0KMiBjb3B5IGdldCBkdXAgXyBuZQ0Kew0KY3Z4IGV4ZWMg X3NjDQp9DQp7DQpwb3ANCn0gaWZlbHNlDQoyIGNvcHkgMSBhZGQgZ2V0IGR1cCBfIG5lDQp7 DQphbG9hZCBwb3AgZmluZGZvbnQgX3NtDQoxMCBjb3B5IDYgbnBvcCBwYXR0ZXJuYXNob3dz dHJva2UNCn0NCnsNCnBvcCA3IGNvcHkgMyBucG9wIHNzDQp9IGlmZWxzZQ0KZ3Jlc3RvcmUN CnBvcA0KfSBmb3INCnBvcA0KfSBmb3INCnJlc3RvcmUNCnBvcCBzdyBybW92ZXRvDQp9IGRk ZWYNCi9fcGpzcw0Kew0Kc2F2ZQ0KMCAxIF9zZGQgbGVuZ3RoIDEgc3ViDQp7DQovX3NkIGV4 Y2ggX3NkZCBleGNoIGdldCBkZGVmDQpfc2QNCjAgMiBfc2QgbGVuZ3RoIDIgc3ViDQp7DQpn c2F2ZQ0KMiBjb3B5IGdldCBkdXAgXyBuZQ0Kew0KY3Z4IGV4ZWMgX3NjDQp9DQp7DQpwb3AN Cn0gaWZlbHNlDQoyIGNvcHkgMSBhZGQgZ2V0IGR1cCBfIG5lDQp7DQphbG9hZCBwb3AgZmlu ZGZvbnQgX3NtDQoxMyBjb3B5IDYgbnBvcCBwYXR0ZXJuYXdpZHRoc2hvd3N0cm9rZQ0KfQ0K ew0KcG9wIDEwIGNvcHkgMyBucG9wIGpzcw0KfSBpZmVsc2UNCmdyZXN0b3JlDQpwb3ANCn0g Zm9yDQpwb3ANCn0gZm9yDQpyZXN0b3JlDQpwb3Agc3dqIHJtb3ZldG8NCn0gZGRlZg0KL19s cCAvbm9uZSBkZGVmDQp9IGRlZg0NCgovQQ0Kew0KcG9wDQp9IGRlZg0NCgovbmMgMyBkaWN0 IGRlZg0KbmMgYmVnaW4NCi9zZXRncmF5DQp7DQpwb3ANCn0gYmluZCBkZWYNCi9zZXRjbXlr Y29sb3INCnsNCjQgbnBvcA0KfSBiaW5kIGRlZg0KL3NldGN1c3RvbWNvbG9yDQp7DQoyIG5w b3ANCn0gYmluZCBkZWYNCmN1cnJlbnRkaWN0IHJlYWRvbmx5IHBvcCBlbmQNCi9aIHtmaW5k Zm9udCBiZWdpbiBjdXJyZW50ZGljdCBkdXAgbGVuZ3RoIGRpY3QgYmVnaW4NCnsxIGluZGV4 IC9GSUQgbmUge2RlZn0ge3BvcCBwb3B9IGlmZWxzZX0gZm9yYWxsIC9Gb250TmFtZSBleGNo IGRlZiBkdXAgbGVuZ3RoIDAgbmUNCnsvRW5jb2RpbmcgRW5jb2RpbmcgMjU2IGFycmF5IGNv cHkgZGVmIDAgZXhjaCB7ZHVwIHR5cGUgL25hbWV0eXBlIGVxDQp7RW5jb2RpbmcgMiBpbmRl eCAyIGluZGV4IHB1dCBwb3AgMSBhZGR9IHtleGNoIHBvcH0gaWZlbHNlfSBmb3JhbGx9IGlm IHBvcA0KY3VycmVudGRpY3QgZHVwIGVuZCBlbmQgL0ZvbnROYW1lIGdldCBleGNoIGRlZmlu ZWZvbnQgcG9wfSBiaW5kIGRlZg0KY3VycmVudGRpY3QgcmVhZG9ubHkgcG9wIGVuZA0Kc2V0 cGFja2luZw0KL2Fubm90YXRlcGFnZQ0Kew0KfSBkZWYNCg0KJSVFbmRSZXNvdXJjZQ0KJUFJ My1HcmlkLjAgMCAwIDAgMCAwIDAgMg0KJSVFbmRQcm9sb2cNCiUlQmVnaW5TZXR1cA0KQWRv YmVfY3Nob3cgL2luaXRpYWxpemUgZ2V0IGV4ZWMNCkFkb2JlX2N1c3RvbWNvbG9yIC9pbml0 aWFsaXplIGdldCBleGVjDQpBZG9iZV90eXBvZ3JhcGh5X0FJMyAvaW5pdGlhbGl6ZSBnZXQg ZXhlYw0KQWRvYmVfSWxsdXN0cmF0b3JfQUkzIC9pbml0aWFsaXplIGdldCBleGVjDQolJUJl Z2luRW5jb2Rpbmc6X0hlbHZldGljYSBIZWx2ZXRpY2ENClsNCjM5L3F1b3Rlc2luZ2xlIDk2 L2dyYXZlIDEzMC9xdW90ZXNpbmdsYmFzZSAxMzEvZmxvcmluIDEzMi9xdW90ZWRibGJhc2UN CjEzMy9lbGxpcHNpcyAxMzQvZGFnZ2VyIDEzNS9kYWdnZXJkYmwgMTM2L2NpcmN1bWZsZXgg MTM3L3BlcnRob3VzYW5kIA0KMTM4L1NjYXJvbiAxMzkvZ3VpbHNpbmdsbGVmdCAxNDAvT0Ug MTQ1L3F1b3RlbGVmdCAxNDYvcXVvdGVyaWdodCANCjE0Ny9xdW90ZWRibGxlZnQgMTQ4L3F1 b3RlZGJscmlnaHQgMTQ5L2J1bGxldCAxNTAvZW5kYXNoIDE1MS9lbWRhc2ggDQoxNTIvdGls ZGUgMTUzL3RyYWRlbWFyayAxNTQvc2Nhcm9uIDE1NS9ndWlsc2luZ2xyaWdodCAxNTYvb2Ug MTU3L2RvdGxlc3NpIA0KMTU5L1lkaWVyZXNpcyAxNjQvY3VycmVuY3kgMTY2L2Jyb2tlbmJh ciAxNjgvZGllcmVzaXMgMTY5L2NvcHlyaWdodCANCjE3MC9vcmRmZW1pbmluZSAxNzIvbG9n aWNhbG5vdCAxNzQvcmVnaXN0ZXJlZCAxNzUvbWFjcm9uIDE3Ni9yaW5nIA0KMTc3L3BsdXNt aW51cyAxNzgvdHdvc3VwZXJpb3IgMTc5L3RocmVlc3VwZXJpb3IgMTgwL2FjdXRlIDE4MS9t dSANCjE4My9wZXJpb2RjZW50ZXJlZCAxODQvY2VkaWxsYSAxODUvb25lc3VwZXJpb3IgMTg2 L29yZG1hc2N1bGluZSANCjE4OC9vbmVxdWFydGVyIDE4OS9vbmVoYWxmIDE5MC90aHJlZXF1 YXJ0ZXJzIDE5Mi9BZ3JhdmUgMTkzL0FhY3V0ZSANCjE5NC9BY2lyY3VtZmxleCAxOTUvQXRp bGRlIDE5Ni9BZGllcmVzaXMgMTk3L0FyaW5nIDE5OC9BRSAxOTkvQ2NlZGlsbGEgDQoyMDAv RWdyYXZlIDIwMS9FYWN1dGUgMjAyL0VjaXJjdW1mbGV4IDIwMy9FZGllcmVzaXMgMjA0L0ln cmF2ZSAyMDUvSWFjdXRlIA0KMjA2L0ljaXJjdW1mbGV4IDIwNy9JZGllcmVzaXMgMjA4L0V0 aCAyMDkvTnRpbGRlIDIxMC9PZ3JhdmUgMjExL09hY3V0ZSANCjIxMi9PY2lyY3VtZmxleCAy MTMvT3RpbGRlIDIxNC9PZGllcmVzaXMgMjE1L211bHRpcGx5IDIxNi9Pc2xhc2ggDQoyMTcv VWdyYXZlIDIxOC9VYWN1dGUgMjE5L1VjaXJjdW1mbGV4IDIyMC9VZGllcmVzaXMgMjIxL1lh Y3V0ZSAyMjIvVGhvcm4gDQoyMjMvZ2VybWFuZGJscyAyMjQvYWdyYXZlIDIyNS9hYWN1dGUg MjI2L2FjaXJjdW1mbGV4IDIyNy9hdGlsZGUgMjI4L2FkaWVyZXNpcyANCjIyOS9hcmluZyAy MzAvYWUgMjMxL2NjZWRpbGxhIDIzMi9lZ3JhdmUgMjMzL2VhY3V0ZSAyMzQvZWNpcmN1bWZs ZXggDQoyMzUvZWRpZXJlc2lzIDIzNi9pZ3JhdmUgMjM3L2lhY3V0ZSAyMzgvaWNpcmN1bWZs ZXggMjM5L2lkaWVyZXNpcyANCjI0MC9ldGggMjQxL250aWxkZSAyNDIvb2dyYXZlIDI0My9v YWN1dGUgMjQ0L29jaXJjdW1mbGV4IDI0NS9vdGlsZGUgDQoyNDYvb2RpZXJlc2lzIDI0Ny9k aXZpZGUgMjQ4L29zbGFzaCAyNDkvdWdyYXZlIDI1MC91YWN1dGUgMjUxL3VjaXJjdW1mbGV4 IA0KMjUyL3VkaWVyZXNpcyAyNTMveWFjdXRlIDI1NC90aG9ybiAyNTUveWRpZXJlc2lzDQpd ICAvX0hlbHZldGljYS9IZWx2ZXRpY2EgWg0KJSVFbmRFbmNvZGluZw0KJSVFbmRTZXR1cA0K ICAwLjAwMCAwLjAwMCAwLjAwMCAwLjAwMCBrDQogWzEgMiBdIDAgZA0KICAwLjAwMCAwLjAw MCAwLjAwMCAxLjAwMCBLDQoyIGoNCnUNCiAgMzk0LjI1MDAgMTUwLjc1MDAgbQ0KICA1NTUu NzUwMCAxNTAuNzUwMCBMDQogIDU1NS43NTAwIDM3LjI1MDAgTA0KICAzOTQuMjUwMCAzNy4y NTAwIEwNCiAgMzk0LjI1MDAgMTUwLjc1MDAgTA0KQg0KICA0NzUuMDAwMCA5NC4wMDAwIG0N CkINClUNCnUNCiBbXSAwIGQNCjEgSg0KICAzODIuMDAwMCAxMjEuMjUwMCBtDQogIDM4Mi4y NTAwIDEyMS4wMDAwIEwNClMNClUNCnUNCiAgMzU0LjAwMDAgMTIxLjAwMDAgbQ0KICAzNTQu NTAwMCAxMjEuNTAwMCBMDQpTDQpVDQp1DQogIDM2OC4wMDAwIDc4Ljc1MDAgbQ0KICAzNjgu MjUwMCA3OS4wMDAwIEwNClMNClUNCnUNCiAgMzY3LjUwMDAgNzguNTAwMCBtDQogIDM2OC4w MDAwIDc4Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzNjcuMDAwMCA3OC41MDAwIG0NCiAgMzY3LjUw MDAgNzguNTAwMCBMDQpTDQpVDQp1DQogIDM2Ni43NTAwIDc4LjI1MDAgbQ0KICAzNjcuMDAw MCA3OC41MDAwIEwNClMNClUNCnUNCiAgMzY2LjI1MDAgNzguMjUwMCBtDQogIDM2Ni43NTAw IDc4LjI1MDAgTA0KUw0KVQ0KdQ0KICAzNjYuMDAwMCA3OC4wMDAwIG0NCiAgMzY2LjI1MDAg NzguMjUwMCBMDQpTDQpVDQp1DQogIDM2NS41MDAwIDc4LjAwMDAgbQ0KICAzNjYuMDAwMCA3 OC4wMDAwIEwNClMNClUNCnUNCiAgMzY1LjI1MDAgNzcuNzUwMCBtDQogIDM2NS41MDAwIDc4 LjAwMDAgTA0KUw0KVQ0KdQ0KICAzNjQuNzUwMCA3Ny43NTAwIG0NCiAgMzY1LjI1MDAgNzcu NzUwMCBMDQpTDQpVDQp1DQogIDM2NC41MDAwIDc3Ljc1MDAgbQ0KICAzNjQuNzUwMCA3Ny43 NTAwIEwNClMNClUNCnUNCiAgMzY0LjAwMDAgNzcuNzUwMCBtDQogIDM2NC41MDAwIDc3Ljc1 MDAgTA0KUw0KVQ0KdQ0KICAzNjMuNzUwMCA3Ny43NTAwIG0NCiAgMzY0LjAwMDAgNzcuNzUw MCBMDQpTDQpVDQp1DQogIDM2My41MDAwIDc3Ljc1MDAgbQ0KICAzNjMuNzUwMCA3Ny43NTAw IEwNClMNClUNCnUNCiAgMzYzLjI1MDAgNzcuNzUwMCBtDQogIDM2My41MDAwIDc3Ljc1MDAg TA0KUw0KVQ0KdQ0KICAzNjMuMDAwMCA3OC4wMDAwIG0NCiAgMzYzLjI1MDAgNzcuNzUwMCBM DQpTDQpVDQp1DQogIDM2Mi43NTAwIDc4LjAwMDAgbQ0KICAzNjMuMDAwMCA3OC4wMDAwIEwN ClMNClUNCnUNCiAgMzYyLjUwMDAgNzguMDAwMCBtDQogIDM2Mi43NTAwIDc4LjAwMDAgTA0K Uw0KVQ0KdQ0KICAzNjIuMjUwMCA3OC4yNTAwIG0NCiAgMzYyLjUwMDAgNzguMDAwMCBMDQpT DQpVDQp1DQogIDM2Mi4wMDAwIDc4LjI1MDAgbQ0KICAzNjIuMjUwMCA3OC4yNTAwIEwNClMN ClUNCnUNCiAgMzYxLjc1MDAgNzguMjUwMCBtDQogIDM2Mi4wMDAwIDc4LjI1MDAgTA0KUw0K VQ0KdQ0KICAzNjEuNTAwMCA3OC41MDAwIG0NCiAgMzYxLjc1MDAgNzguMjUwMCBMDQpTDQpV DQp1DQogIDM2MS4yNTAwIDc4LjUwMDAgbQ0KICAzNjEuNTAwMCA3OC41MDAwIEwNClMNClUN CnUNCiAgMzYxLjAwMDAgNzguNzUwMCBtDQogIDM2MS4yNTAwIDc4LjUwMDAgTA0KUw0KVQ0K dQ0KICAzNjAuNzUwMCA3OS4wMDAwIG0NCiAgMzYxLjAwMDAgNzguNzUwMCBMDQpTDQpVDQp1 DQogIDM2MC41MDAwIDc5LjI1MDAgbQ0KICAzNjAuNzUwMCA3OS4wMDAwIEwNClMNClUNCnUN CiAgMzYwLjI1MDAgNzkuNTAwMCBtDQogIDM2MC41MDAwIDc5LjI1MDAgTA0KUw0KVQ0KdQ0K ICAzNjAuMDAwMCA3OS41MDAwIG0NCiAgMzYwLjI1MDAgNzkuNTAwMCBMDQpTDQpVDQp1DQog IDM2MC4wMDAwIDc5Ljc1MDAgbQ0KICAzNjAuMDAwMCA3OS41MDAwIEwNClMNClUNCnUNCiAg MzU5Ljc1MDAgODAuMDAwMCBtDQogIDM2MC4wMDAwIDc5Ljc1MDAgTA0KUw0KVQ0KdQ0KICAz NTkuNTAwMCA4MC4yNTAwIG0NCiAgMzU5Ljc1MDAgODAuMDAwMCBMDQpTDQpVDQp1DQogIDM1 OS4yNTAwIDgwLjUwMDAgbQ0KICAzNTkuNTAwMCA4MC4yNTAwIEwNClMNClUNCnUNCiAgMzU5 LjI1MDAgODAuNzUwMCBtDQogIDM1OS4yNTAwIDgwLjUwMDAgTA0KUw0KVQ0KdQ0KICAzNTku MDAwMCA4MS4wMDAwIG0NCiAgMzU5LjI1MDAgODAuNzUwMCBMDQpTDQpVDQp1DQogIDM1OS4w MDAwIDgxLjAwMDAgbQ0KICAzNTkuMDAwMCA4MS4wMDAwIEwNClMNClUNCnUNCiAgMzU5LjAw MDAgODEuMjUwMCBtDQogIDM1OS4wMDAwIDgxLjAwMDAgTA0KUw0KVQ0KdQ0KICAzNTkuMDAw MCA4MS4yNTAwIG0NCiAgMzU5LjAwMDAgODEuMDAwMCBMDQpTDQpVDQp1DQogIDM1OC43NTAw IDgxLjI1MDAgbQ0KICAzNTkuMDAwMCA4MS4yNTAwIEwNClMNClUNCnUNCiAgMzU4LjUwMDAg ODEuMjUwMCBtDQogIDM1OC43NTAwIDgxLjI1MDAgTA0KUw0KVQ0KdQ0KICAzNTguNTAwMCA4 MS4wMDAwIG0NCiAgMzU4LjUwMDAgODEuMjUwMCBMDQpTDQpVDQp1DQogIDM1OC41MDAwIDgx LjAwMDAgbQ0KICAzNTguNTAwMCA4MS4yNTAwIEwNClMNClUNCnUNCiAgMzU4LjI1MDAgODEu MDAwMCBtDQogIDM1OC41MDAwIDgxLjAwMDAgTA0KUw0KVQ0KdQ0KICAzNTguMDAwMCA4MC41 MDAwIG0NCiAgMzU4LjI1MDAgODEuMDAwMCBMDQpTDQpVDQp1DQogIDM1OC4wMDAwIDgwLjUw MDAgbQ0KICAzNTguMDAwMCA4MC41MDAwIEwNClMNClUNCnUNCiAgMzU3Ljc1MDAgODAuMjUw MCBtDQogIDM1OC4wMDAwIDgwLjUwMDAgTA0KUw0KVQ0KdQ0KICAzNTcuNTAwMCA4MC4wMDAw IG0NCiAgMzU3Ljc1MDAgODAuMjUwMCBMDQpTDQpVDQp1DQogIDM1Ny4yNTAwIDc5Ljc1MDAg bQ0KICAzNTcuNTAwMCA4MC4wMDAwIEwNClMNClUNCnUNCiAgMzU3LjAwMDAgNzkuNTAwMCBt DQogIDM1Ny4yNTAwIDc5Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzNTYuNzUwMCA3OS4yNTAwIG0N CiAgMzU3LjAwMDAgNzkuNTAwMCBMDQpTDQpVDQp1DQogIDM1Ni4yNTAwIDc5LjAwMDAgbQ0K ICAzNTYuNzUwMCA3OS4yNTAwIEwNClMNClUNCnUNCiAgMzU2LjAwMDAgNzguNzUwMCBtDQog IDM1Ni4yNTAwIDc5LjAwMDAgTA0KUw0KVQ0KdQ0KICAzNTUuNTAwMCA3OC41MDAwIG0NCiAg MzU2LjAwMDAgNzguNzUwMCBMDQpTDQpVDQp1DQogIDM1NS4yNTAwIDc4LjI1MDAgbQ0KICAz NTUuNTAwMCA3OC41MDAwIEwNClMNClUNCnUNCiAgMzU0Ljc1MDAgNzguMDAwMCBtDQogIDM1 NS4yNTAwIDc4LjI1MDAgTA0KUw0KVQ0KdQ0KICAzNTQuMjUwMCA3Ny43NTAwIG0NCiAgMzU0 Ljc1MDAgNzguMDAwMCBMDQpTDQpVDQp1DQogIDM1My43NTAwIDc3Ljc1MDAgbQ0KICAzNTQu MjUwMCA3Ny43NTAwIEwNClMNClUNCnUNCiAgMzUzLjI1MDAgNzcuNTAwMCBtDQogIDM1My43 NTAwIDc3Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzNTIuNzUwMCA3Ny41MDAwIG0NCiAgMzUzLjI1 MDAgNzcuNTAwMCBMDQpTDQpVDQp1DQogIDM1Mi4yNTAwIDc3LjUwMDAgbQ0KICAzNTIuNzUw MCA3Ny41MDAwIEwNClMNClUNCnUNCiAgMzUxLjUwMDAgNzcuMjUwMCBtDQogIDM1Mi4yNTAw IDc3LjUwMDAgTA0KUw0KVQ0KdQ0KICAzNTEuMDAwMCA3Ny4yNTAwIG0NCiAgMzUxLjUwMDAg NzcuMjUwMCBMDQpTDQpVDQp1DQogIDM1MC43NTAwIDc3LjI1MDAgbQ0KICAzNTEuMDAwMCA3 Ny4yNTAwIEwNClMNClUNCnUNCiAgMzUwLjI1MDAgNzcuMjUwMCBtDQogIDM1MC43NTAwIDc3 LjI1MDAgTA0KUw0KVQ0KdQ0KICAzNDkuNzUwMCA3Ny4yNTAwIG0NCiAgMzUwLjI1MDAgNzcu MjUwMCBMDQpTDQpVDQp1DQogIDM0OS4yNTAwIDc3LjI1MDAgbQ0KICAzNDkuNzUwMCA3Ny4y NTAwIEwNClMNClUNCnUNCiAgMzQ4Ljc1MDAgNzcuMjUwMCBtDQogIDM0OS4yNTAwIDc3LjI1 MDAgTA0KUw0KVQ0KdQ0KICAzNDguNTAwMCA3Ny4yNTAwIG0NCiAgMzQ4Ljc1MDAgNzcuMjUw MCBMDQpTDQpVDQp1DQogIDM0OC4wMDAwIDc3LjI1MDAgbQ0KICAzNDguNTAwMCA3Ny4yNTAw IEwNClMNClUNCnUNCiAgMzQ3Ljc1MDAgNzcuMjUwMCBtDQogIDM0OC4wMDAwIDc3LjI1MDAg TA0KUw0KVQ0KdQ0KICAzNDcuMjUwMCA3Ny41MDAwIG0NCiAgMzQ3Ljc1MDAgNzcuMjUwMCBM DQpTDQpVDQp1DQogIDM0Ni43NTAwIDc3LjUwMDAgbQ0KICAzNDcuMjUwMCA3Ny41MDAwIEwN ClMNClUNCnUNCiAgMzQ2LjI1MDAgNzcuNzUwMCBtDQogIDM0Ni43NTAwIDc3LjUwMDAgTA0K Uw0KVQ0KdQ0KICAzNDUuNzUwMCA3OC4wMDAwIG0NCiAgMzQ2LjI1MDAgNzcuNzUwMCBMDQpT DQpVDQp1DQogIDM0NS4yNTAwIDc4LjI1MDAgbQ0KICAzNDUuNzUwMCA3OC4wMDAwIEwNClMN ClUNCnUNCiAgMzQ0Ljc1MDAgNzguNTAwMCBtDQogIDM0NS4yNTAwIDc4LjI1MDAgTA0KUw0K VQ0KdQ0KICAzNDQuNTAwMCA3OC43NTAwIG0NCiAgMzQ0Ljc1MDAgNzguNTAwMCBMDQpTDQpV DQp1DQogIDM0NC4wMDAwIDc5LjAwMDAgbQ0KICAzNDQuNTAwMCA3OC43NTAwIEwNClMNClUN CnUNCiAgMzQzLjc1MDAgNzkuNTAwMCBtDQogIDM0NC4wMDAwIDc5LjAwMDAgTA0KUw0KVQ0K dQ0KICAzNDMuMjUwMCA3OS43NTAwIG0NCiAgMzQzLjc1MDAgNzkuNTAwMCBMDQpTDQpVDQp1 DQogIDM0My4wMDAwIDgwLjAwMDAgbQ0KICAzNDMuMjUwMCA3OS43NTAwIEwNClMNClUNCnUN CiAgMzQyLjUwMDAgODAuNTAwMCBtDQogIDM0My4wMDAwIDgwLjAwMDAgTA0KUw0KVQ0KdQ0K ICAzNDIuNTAwMCA4MC43NTAwIG0NCiAgMzQyLjUwMDAgODAuNTAwMCBMDQpTDQpVDQp1DQog IDM0Mi4yNTAwIDgxLjAwMDAgbQ0KICAzNDIuNTAwMCA4MC43NTAwIEwNClMNClUNCnUNCiAg MzQyLjAwMDAgODEuNTAwMCBtDQogIDM0Mi4yNTAwIDgxLjAwMDAgTA0KUw0KVQ0KdQ0KICAz NDEuNzUwMCA4MS43NTAwIG0NCiAgMzQyLjAwMDAgODEuNTAwMCBMDQpTDQpVDQp1DQogIDM0 MS43NTAwIDgyLjI1MDAgbQ0KICAzNDEuNzUwMCA4MS43NTAwIEwNClMNClUNCnUNCiAgMzQx LjUwMDAgODIuNTAwMCBtDQogIDM0MS43NTAwIDgyLjI1MDAgTA0KUw0KVQ0KdQ0KICAzNDEu NTAwMCA4Mi43NTAwIG0NCiAgMzQxLjc1MDAgODIuNTAwMCBMDQpTDQpVDQp1DQogIDM0MS41 MDAwIDgzLjAwMDAgbQ0KICAzNDEuNTAwMCA4Mi43NTAwIEwNClMNClUNCnUNCiAgMzQxLjUw MDAgODMuMjUwMCBtDQogIDM0MS41MDAwIDgzLjAwMDAgTA0KUw0KVQ0KdQ0KICAzNDEuNTAw MCA4My43NTAwIG0NCiAgMzQxLjUwMDAgODMuMjUwMCBMDQpTDQpVDQp1DQogIDM0MS41MDAw IDg0LjAwMDAgbQ0KICAzNDEuNTAwMCA4My43NTAwIEwNClMNClUNCnUNCiAgMzQxLjUwMDAg ODQuMjUwMCBtDQogIDM0MS41MDAwIDg0LjAwMDAgTA0KUw0KVQ0KdQ0KICAzNDEuNTAwMCA4 NC41MDAwIG0NCiAgMzQxLjUwMDAgODQuMjUwMCBMDQpTDQpVDQp1DQogIDM0MS41MDAwIDg0 Ljc1MDAgbQ0KICAzNDEuNTAwMCA4NC41MDAwIEwNClMNClUNCnUNCiAgMzQxLjUwMDAgODUu MDAwMCBtDQogIDM0MS41MDAwIDg0Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzNDEuNTAwMCA4NS4y NTAwIG0NCiAgMzQxLjUwMDAgODUuMDAwMCBMDQpTDQpVDQp1DQogIDM0MS41MDAwIDg1LjUw MDAgbQ0KICAzNDEuNTAwMCA4NS4yNTAwIEwNClMNClUNCnUNCiAgMzQxLjUwMDAgODUuNzUw MCBtDQogIDM0MS41MDAwIDg1LjUwMDAgTA0KUw0KVQ0KdQ0KICAzNDEuNTAwMCA4Ni4wMDAw IG0NCiAgMzQxLjUwMDAgODUuNzUwMCBMDQpTDQpVDQp1DQogIDM0MS41MDAwIDg2LjI1MDAg bQ0KICAzNDEuNTAwMCA4Ni4wMDAwIEwNClMNClUNCnUNCiAgMzQxLjUwMDAgODYuNTAwMCBt DQogIDM0MS41MDAwIDg2LjI1MDAgTA0KUw0KVQ0KdQ0KICAzNDEuNzUwMCA4Ni43NTAwIG0N CiAgMzQxLjUwMDAgODYuNTAwMCBMDQpTDQpVDQp1DQogIDM0MS41MDAwIDg3LjAwMDAgbQ0K ICAzNDEuNTAwMCA4Ni43NTAwIEwNClMNClUNCnUNCiAgMzQxLjc1MDAgODcuMjUwMCBtDQog IDM0MS41MDAwIDg3LjAwMDAgTA0KUw0KVQ0KdQ0KICAzNDEuNzUwMCA4Ny41MDAwIG0NCiAg MzQxLjc1MDAgODcuMjUwMCBMDQpTDQpVDQp1DQogIDM0MS43NTAwIDg3Ljc1MDAgbQ0KICAz NDEuNzUwMCA4Ny41MDAwIEwNClMNClUNCnUNCiAgMzQxLjc1MDAgODcuNzUwMCBtDQogIDM0 MS43NTAwIDg3Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzNDEuNTAwMCA4Ny43NTAwIG0NCiAgMzQx Ljc1MDAgODcuNzUwMCBMDQpTDQpVDQp1DQogIDM0MS41MDAwIDg4LjAwMDAgbQ0KICAzNDEu NzUwMCA4Ny43NTAwIEwNClMNClUNCnUNCiAgMzQxLjI1MDAgODguMDAwMCBtDQogIDM0MS41 MDAwIDg4LjAwMDAgTA0KUw0KVQ0KdQ0KICAzNDEuMDAwMCA4Ny43NTAwIG0NCiAgMzQxLjI1 MDAgODguMDAwMCBMDQpTDQpVDQp1DQogIDM0MC41MDAwIDg3Ljc1MDAgbQ0KICAzNDEuMDAw MCA4Ny43NTAwIEwNClMNClUNCnUNCiAgMzQwLjI1MDAgODcuNzUwMCBtDQogIDM0MC41MDAw IDg3Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzMzkuNzUwMCA4Ny41MDAwIG0NCiAgMzQwLjI1MDAg ODcuNzUwMCBMDQpTDQpVDQp1DQogIDMzOS4yNTAwIDg3LjUwMDAgbQ0KICAzMzkuNzUwMCA4 Ny41MDAwIEwNClMNClUNCnUNCiAgMzM4Ljc1MDAgODcuNTAwMCBtDQogIDMzOS4yNTAwIDg3 LjUwMDAgTA0KUw0KVQ0KdQ0KICAzMzguMjUwMCA4Ny4yNTAwIG0NCiAgMzM4Ljc1MDAgODcu NTAwMCBMDQpTDQpVDQp1DQogIDMzNy43NTAwIDg3LjI1MDAgbQ0KICAzMzguMjUwMCA4Ny4y NTAwIEwNClMNClUNCnUNCiAgMzM3LjI1MDAgODcuMjUwMCBtDQogIDMzNy43NTAwIDg3LjI1 MDAgTA0KUw0KVQ0KdQ0KICAzMzYuNzUwMCA4Ny4yNTAwIG0NCiAgMzM3LjI1MDAgODcuMjUw MCBMDQpTDQpVDQp1DQogIDMzNi4yNTAwIDg3LjI1MDAgbQ0KICAzMzYuNzUwMCA4Ny4yNTAw IEwNClMNClUNCnUNCiAgMzM1Ljc1MDAgODcuMjUwMCBtDQogIDMzNi4yNTAwIDg3LjI1MDAg TA0KUw0KVQ0KdQ0KICAzMzUuMjUwMCA4Ny4yNTAwIG0NCiAgMzM1Ljc1MDAgODcuMjUwMCBM DQpTDQpVDQp1DQogIDMzNC43NTAwIDg3LjI1MDAgbQ0KICAzMzUuMjUwMCA4Ny4yNTAwIEwN ClMNClUNCnUNCiAgMzM0LjI1MDAgODcuNTAwMCBtDQogIDMzNC43NTAwIDg3LjI1MDAgTA0K Uw0KVQ0KdQ0KICAzMzMuNTAwMCA4Ny41MDAwIG0NCiAgMzM0LjI1MDAgODcuNTAwMCBMDQpT DQpVDQp1DQogIDMzMy4yNTAwIDg3Ljc1MDAgbQ0KICAzMzMuNTAwMCA4Ny41MDAwIEwNClMN ClUNCnUNCiAgMzMyLjUwMDAgODguMDAwMCBtDQogIDMzMy4yNTAwIDg3Ljc1MDAgTA0KUw0K VQ0KdQ0KICAzMzIuMjUwMCA4OC41MDAwIG0NCiAgMzMyLjUwMDAgODguMDAwMCBMDQpTDQpV DQp1DQogIDMzMS43NTAwIDg4Ljc1MDAgbQ0KICAzMzIuMjUwMCA4OC41MDAwIEwNClMNClUN CnUNCiAgMzMxLjI1MDAgODkuMDAwMCBtDQogIDMzMS43NTAwIDg4Ljc1MDAgTA0KUw0KVQ0K dQ0KICAzMzEuMDAwMCA4OS4yNTAwIG0NCiAgMzMxLjI1MDAgODkuMDAwMCBMDQpTDQpVDQp1 DQogIDMzMC41MDAwIDg5LjUwMDAgbQ0KICAzMzEuMDAwMCA4OS4yNTAwIEwNClMNClUNCnUN CiAgMzMwLjI1MDAgOTAuMDAwMCBtDQogIDMzMC41MDAwIDg5LjUwMDAgTA0KUw0KVQ0KdQ0K ICAzMzAuMDAwMCA5MC4yNTAwIG0NCiAgMzMwLjI1MDAgOTAuMDAwMCBMDQpTDQpVDQp1DQog IDMyOS43NTAwIDkwLjUwMDAgbQ0KICAzMzAuMDAwMCA5MC4yNTAwIEwNClMNClUNCnUNCiAg MzI5LjUwMDAgOTAuNzUwMCBtDQogIDMyOS43NTAwIDkwLjUwMDAgTA0KUw0KVQ0KdQ0KICAz MjkuNTAwMCA5MS4yNTAwIG0NCiAgMzI5LjUwMDAgOTAuNzUwMCBMDQpTDQpVDQp1DQogIDMy OS4yNTAwIDkxLjUwMDAgbQ0KICAzMjkuNTAwMCA5MS4yNTAwIEwNClMNClUNCnUNCiAgMzI5 LjI1MDAgOTEuNzUwMCBtDQogIDMyOS4yNTAwIDkxLjUwMDAgTA0KUw0KVQ0KdQ0KICAzMjku MjUwMCA5Mi4yNTAwIG0NCiAgMzI5LjI1MDAgOTEuNzUwMCBMDQpTDQpVDQp1DQogIDMyOS4w MDAwIDkyLjUwMDAgbQ0KICAzMjkuMjUwMCA5Mi4yNTAwIEwNClMNClUNCnUNCiAgMzI5LjAw MDAgOTMuMDAwMCBtDQogIDMyOS4wMDAwIDkyLjUwMDAgTA0KUw0KVQ0KdQ0KICAzMjkuMDAw MCA5My4yNTAwIG0NCiAgMzI5LjAwMDAgOTMuMDAwMCBMDQpTDQpVDQp1DQogIDMyOS4wMDAw IDkzLjUwMDAgbQ0KICAzMjkuMDAwMCA5My4yNTAwIEwNClMNClUNCnUNCiAgMzI5LjI1MDAg OTQuMDAwMCBtDQogIDMyOS4wMDAwIDkzLjUwMDAgTA0KUw0KVQ0KdQ0KICAzMjkuMjUwMCA5 NC4yNTAwIG0NCiAgMzI5LjI1MDAgOTQuMDAwMCBMDQpTDQpVDQp1DQogIDMyOS4yNTAwIDk0 LjUwMDAgbQ0KICAzMjkuMjUwMCA5NC4yNTAwIEwNClMNClUNCnUNCiAgMzI5LjI1MDAgOTQu NzUwMCBtDQogIDMyOS4yNTAwIDk0LjUwMDAgTA0KUw0KVQ0KdQ0KICAzMjkuMjUwMCA5NS4y NTAwIG0NCiAgMzI5LjI1MDAgOTQuNzUwMCBMDQpTDQpVDQp1DQogIDMyOS41MDAwIDk1LjUw MDAgbQ0KICAzMjkuMjUwMCA5NS4yNTAwIEwNClMNClUNCnUNCiAgMzI5LjUwMDAgOTUuNzUw MCBtDQogIDMyOS41MDAwIDk1LjUwMDAgTA0KUw0KVQ0KdQ0KICAzMjkuNzUwMCA5Ni4wMDAw IG0NCiAgMzI5LjUwMDAgOTUuNzUwMCBMDQpTDQpVDQp1DQogIDMyOS43NTAwIDk2LjI1MDAg bQ0KICAzMjkuNTAwMCA5Ni4wMDAwIEwNClMNClUNCnUNCiAgMzMwLjAwMDAgOTYuNTAwMCBt DQogIDMyOS43NTAwIDk2LjI1MDAgTA0KUw0KVQ0KdQ0KICAzMzAuMDAwMCA5Ni43NTAwIG0N CiAgMzMwLjAwMDAgOTYuNTAwMCBMDQpTDQpVDQp1DQogIDMzMC4yNTAwIDk3LjAwMDAgbQ0K ICAzMzAuMDAwMCA5Ni43NTAwIEwNClMNClUNCnUNCiAgMzMwLjI1MDAgOTcuMjUwMCBtDQog IDMzMC4yNTAwIDk3LjAwMDAgTA0KUw0KVQ0KdQ0KICAzMzAuNTAwMCA5Ny41MDAwIG0NCiAg MzMwLjI1MDAgOTcuMjUwMCBMDQpTDQpVDQp1DQogIDMzMC43NTAwIDk3Ljc1MDAgbQ0KICAz MzAuNTAwMCA5Ny41MDAwIEwNClMNClUNCnUNCiAgMzMxLjAwMDAgOTguMDAwMCBtDQogIDMz MC43NTAwIDk3Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzMzEuMDAwMCA5OC4yNTAwIG0NCiAgMzMx LjAwMDAgOTguMDAwMCBMDQpTDQpVDQp1DQogIDMzMS4yNTAwIDk4LjUwMDAgbQ0KICAzMzEu MDAwMCA5OC4yNTAwIEwNClMNClUNCnUNCiAgMzMxLjUwMDAgOTguNzUwMCBtDQogIDMzMS4y NTAwIDk4LjUwMDAgTA0KUw0KVQ0KdQ0KICAzMzEuNzUwMCA5OS4wMDAwIG0NCiAgMzMxLjUw MDAgOTguNzUwMCBMDQpTDQpVDQp1DQogIDMzMi4yNTAwIDk5LjI1MDAgbQ0KICAzMzEuNzUw MCA5OS4wMDAwIEwNClMNClUNCnUNCiAgMzMyLjUwMDAgOTkuNTAwMCBtDQogIDMzMi4yNTAw IDk5LjI1MDAgTA0KUw0KVQ0KdQ0KICAzMzIuNzUwMCA5OS43NTAwIG0NCiAgMzMyLjUwMDAg OTkuNTAwMCBMDQpTDQpVDQp1DQogIDMzMy4wMDAwIDEwMC4wMDAwIG0NCiAgMzMyLjc1MDAg OTkuNzUwMCBMDQpTDQpVDQp1DQogIDMzMy4yNTAwIDEwMC4yNTAwIG0NCiAgMzMzLjAwMDAg MTAwLjAwMDAgTA0KUw0KVQ0KdQ0KICAzMzMuMjUwMCAxMDAuNTAwMCBtDQogIDMzMy4yNTAw IDEwMC4yNTAwIEwNClMNClUNCnUNCiAgMzMzLjUwMDAgMTAwLjc1MDAgbQ0KICAzMzMuNTAw MCAxMDAuNTAwMCBMDQpTDQpVDQp1DQogIDMzMy41MDAwIDEwMC43NTAwIG0NCiAgMzMzLjUw MDAgMTAwLjc1MDAgTA0KUw0KVQ0KdQ0KICAzMzMuMjUwMCAxMDEuMDAwMCBtDQogIDMzMy41 MDAwIDEwMC43NTAwIEwNClMNClUNCnUNCiAgMzMzLjI1MDAgMTAxLjI1MDAgbQ0KICAzMzMu MjUwMCAxMDEuMDAwMCBMDQpTDQpVDQp1DQogIDMzMy4wMDAwIDEwMS4yNTAwIG0NCiAgMzMz LjI1MDAgMTAxLjI1MDAgTA0KUw0KVQ0KdQ0KICAzMzIuNTAwMCAxMDEuNTAwMCBtDQogIDMz My4wMDAwIDEwMS4yNTAwIEwNClMNClUNCnUNCiAgMzMyLjI1MDAgMTAxLjc1MDAgbQ0KICAz MzIuNTAwMCAxMDEuNTAwMCBMDQpTDQpVDQp1DQogIDMzMi4wMDAwIDEwMi4wMDAwIG0NCiAg MzMyLjI1MDAgMTAxLjc1MDAgTA0KUw0KVQ0KdQ0KICAzMzEuNTAwMCAxMDIuMDAwMCBtDQog IDMzMi4wMDAwIDEwMi4wMDAwIEwNClMNClUNCnUNCiAgMzMxLjI1MDAgMTAyLjI1MDAgbQ0K ICAzMzEuNTAwMCAxMDIuMDAwMCBMDQpTDQpVDQp1DQogIDMzMS4wMDAwIDEwMi41MDAwIG0N CiAgMzMxLjI1MDAgMTAyLjI1MDAgTA0KUw0KVQ0KdQ0KICAzMzAuNTAwMCAxMDMuMDAwMCBt DQogIDMzMS4wMDAwIDEwMi41MDAwIEwNClMNClUNCnUNCiAgMzMwLjI1MDAgMTAzLjAwMDAg bQ0KICAzMzAuNTAwMCAxMDMuMDAwMCBMDQpTDQpVDQp1DQogIDMzMC4wMDAwIDEwMy41MDAw IG0NCiAgMzMwLjI1MDAgMTAzLjAwMDAgTA0KUw0KVQ0KdQ0KICAzMjkuNzUwMCAxMDMuNzUw MCBtDQogIDMzMC4wMDAwIDEwMy41MDAwIEwNClMNClUNCnUNCiAgMzI5LjUwMDAgMTA0LjI1 MDAgbQ0KICAzMjkuNzUwMCAxMDMuNzUwMCBMDQpTDQpVDQp1DQogIDMyOS41MDAwIDEwNC41 MDAwIG0NCiAgMzI5LjUwMDAgMTA0LjI1MDAgTA0KUw0KVQ0KdQ0KICAzMjkuMjUwMCAxMDQu NzUwMCBtDQogIDMyOS41MDAwIDEwNC41MDAwIEwNClMNClUNCnUNCiAgMzI5LjI1MDAgMTA1 LjUwMDAgbQ0KICAzMjkuMjUwMCAxMDQuNzUwMCBMDQpTDQpVDQp1DQogIDMyOS4yNTAwIDEw NS43NTAwIG0NCiAgMzI5LjI1MDAgMTA1LjUwMDAgTA0KUw0KVQ0KdQ0KICAzMjkuMjUwMCAx MDYuMjUwMCBtDQogIDMyOS4yNTAwIDEwNS43NTAwIEwNClMNClUNCnUNCiAgMzI5LjI1MDAg MTA2Ljc1MDAgbQ0KICAzMjkuMjUwMCAxMDYuMjUwMCBMDQpTDQpVDQp1DQogIDMyOS4yNTAw IDEwNy4yNTAwIG0NCiAgMzI5LjI1MDAgMTA2Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzMjkuMjUw MCAxMDcuNzUwMCBtDQogIDMyOS4yNTAwIDEwNy4yNTAwIEwNClMNClUNCnUNCiAgMzI5LjUw MDAgMTA4LjI1MDAgbQ0KICAzMjkuMjUwMCAxMDcuNzUwMCBMDQpTDQpVDQp1DQogIDMyOS41 MDAwIDEwOC43NTAwIG0NCiAgMzI5LjUwMDAgMTA4LjI1MDAgTA0KUw0KVQ0KdQ0KICAzMjku NzUwMCAxMDkuMjUwMCBtDQogIDMyOS41MDAwIDEwOC43NTAwIEwNClMNClUNCnUNCiAgMzMw LjAwMDAgMTA5LjUwMDAgbQ0KICAzMjkuNzUwMCAxMDkuMjUwMCBMDQpTDQpVDQp1DQogIDMz MC4yNTAwIDExMC4wMDAwIG0NCiAgMzMwLjAwMDAgMTA5LjUwMDAgTA0KUw0KVQ0KdQ0KICAz MzAuNTAwMCAxMTAuMjUwMCBtDQogIDMzMC4yNTAwIDExMC4wMDAwIEwNClMNClUNCnUNCiAg MzMxLjAwMDAgMTEwLjc1MDAgbQ0KICAzMzAuNTAwMCAxMTAuMjUwMCBMDQpTDQpVDQp1DQog IDMzMS4yNTAwIDExMS4wMDAwIG0NCiAgMzMxLjAwMDAgMTEwLjc1MDAgTA0KUw0KVQ0KdQ0K ICAzMzEuNTAwMCAxMTEuNTAwMCBtDQogIDMzMS4yNTAwIDExMS4wMDAwIEwNClMNClUNCnUN CiAgMzMyLjAwMDAgMTExLjc1MDAgbQ0KICAzMzEuNTAwMCAxMTEuNTAwMCBMDQpTDQpVDQp1 DQogIDMzMi4yNTAwIDExMi4wMDAwIG0NCiAgMzMyLjAwMDAgMTExLjc1MDAgTA0KUw0KVQ0K dQ0KICAzMzIuNzUwMCAxMTIuMjUwMCBtDQogIDMzMi4yNTAwIDExMi4wMDAwIEwNClMNClUN CnUNCiAgMzMzLjAwMDAgMTEyLjUwMDAgbQ0KICAzMzIuNzUwMCAxMTIuMjUwMCBMDQpTDQpV DQp1DQogIDMzMy41MDAwIDExMi41MDAwIG0NCiAgMzMzLjAwMDAgMTEyLjUwMDAgTA0KUw0K VQ0KdQ0KICAzMzMuNzUwMCAxMTIuNzUwMCBtDQogIDMzMy41MDAwIDExMi41MDAwIEwNClMN ClUNCnUNCiAgMzM0LjI1MDAgMTEzLjAwMDAgbQ0KICAzMzMuNzUwMCAxMTIuNzUwMCBMDQpT DQpVDQp1DQogIDMzNC41MDAwIDExMy4wMDAwIG0NCiAgMzM0LjI1MDAgMTEyLjc1MDAgTA0K Uw0KVQ0KdQ0KICAzMzQuNzUwMCAxMTMuMDAwMCBtDQogIDMzNC41MDAwIDExMy4wMDAwIEwN ClMNClUNCnUNCiAgMzM1LjI1MDAgMTEzLjAwMDAgbQ0KICAzMzQuNzUwMCAxMTMuMDAwMCBM DQpTDQpVDQp1DQogIDMzNS41MDAwIDExMy4yNTAwIG0NCiAgMzM1LjI1MDAgMTEzLjAwMDAg TA0KUw0KVQ0KdQ0KICAzMzUuNzUwMCAxMTMuMjUwMCBtDQogIDMzNS41MDAwIDExMy4yNTAw IEwNClMNClUNCnUNCiAgMzM2LjI1MDAgMTEzLjI1MDAgbQ0KICAzMzUuNzUwMCAxMTMuMjUw MCBMDQpTDQpVDQp1DQogIDMzNi41MDAwIDExMy4yNTAwIG0NCiAgMzM2LjI1MDAgMTEzLjI1 MDAgTA0KUw0KVQ0KdQ0KICAzMzYuNzUwMCAxMTMuNTAwMCBtDQogIDMzNi41MDAwIDExMy4y NTAwIEwNClMNClUNCnUNCiAgMzM3LjAwMDAgMTEzLjc1MDAgbQ0KICAzMzYuNzUwMCAxMTMu NTAwMCBMDQpTDQpVDQp1DQogIDMzNy4yNTAwIDExMy43NTAwIG0NCiAgMzM3LjAwMDAgMTEz Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzMzcuMjUwMCAxMTMuNzUwMCBtDQogIDMzNy4yNTAwIDEx My43NTAwIEwNClMNClUNCnUNCiAgMzM3LjI1MDAgMTE0LjAwMDAgbQ0KICAzMzcuMjUwMCAx MTMuNzUwMCBMDQpTDQpVDQp1DQogIDMzNy41MDAwIDExNC4yNTAwIG0NCiAgMzM3LjI1MDAg MTE0LjAwMDAgTA0KUw0KVQ0KdQ0KICAzMzcuNTAwMCAxMTQuNTAwMCBtDQogIDMzNy41MDAw IDExNC4yNTAwIEwNClMNClUNCnUNCiAgMzM3LjUwMDAgMTE0Ljc1MDAgbQ0KICAzMzcuNTAw MCAxMTQuNTAwMCBMDQpTDQpVDQp1DQogIDMzNy41MDAwIDExNS4wMDAwIG0NCiAgMzM3LjUw MDAgMTE0Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzMzcuNTAwMCAxMTUuMjUwMCBtDQogIDMzNy41 MDAwIDExNS4wMDAwIEwNClMNClUNCnUNCiAgMzM3Ljc1MDAgMTE1LjUwMDAgbQ0KICAzMzcu NTAwMCAxMTUuMjUwMCBMDQpTDQpVDQp1DQogIDMzNy43NTAwIDExNi4wMDAwIG0NCiAgMzM3 LjUwMDAgMTE1LjUwMDAgTA0KUw0KVQ0KdQ0KICAzMzcuNzUwMCAxMTYuMjUwMCBtDQogIDMz Ny43NTAwIDExNi4wMDAwIEwNClMNClUNCnUNCiAgMzM4LjAwMDAgMTE2LjUwMDAgbQ0KICAz MzcuNzUwMCAxMTYuMjUwMCBMDQpTDQpVDQp1DQogIDMzOC4yNTAwIDExNy4wMDAwIG0NCiAg MzM4LjAwMDAgMTE2LjUwMDAgTA0KUw0KVQ0KdQ0KICAzMzguMjUwMCAxMTcuMjUwMCBtDQog IDMzOC4yNTAwIDExNy4wMDAwIEwNClMNClUNCnUNCiAgMzM4LjUwMDAgMTE3Ljc1MDAgbQ0K ICAzMzguMjUwMCAxMTcuMjUwMCBMDQpTDQpVDQp1DQogIDMzOC43NTAwIDExOC4wMDAwIG0N CiAgMzM4LjUwMDAgMTE3Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzMzkuMjUwMCAxMTguNTAwMCBt DQogIDMzOC43NTAwIDExOC4wMDAwIEwNClMNClUNCnUNCiAgMzM5LjUwMDAgMTE4Ljc1MDAg bQ0KICAzMzkuMjUwMCAxMTguNTAwMCBMDQpTDQpVDQp1DQogIDMzOS41MDAwIDExOC43NTAw IG0NCiAgMzM5Ljc1MDAgMTE5LjAwMDAgTA0KUw0KVQ0KdQ0KICAzMzkuNzUwMCAxMTkuMDAw MCBtDQogIDM0MC4yNTAwIDExOS4yNTAwIEwNClMNClUNCnUNCiAgMzQwLjI1MDAgMTE5LjI1 MDAgbQ0KICAzNDAuNTAwMCAxMTkuNTAwMCBMDQpTDQpVDQp1DQogIDM0MC41MDAwIDExOS41 MDAwIG0NCiAgMzQxLjAwMDAgMTE5Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzNDEuMDAwMCAxMTku NzUwMCBtDQogIDM0MS4yNTAwIDEyMC4wMDAwIEwNClMNClUNCnUNCiAgMzQxLjI1MDAgMTIw LjAwMDAgbQ0KICAzNDEuNzUwMCAxMjAuMDAwMCBMDQpTDQpVDQp1DQogIDM0MS43NTAwIDEy MC4wMDAwIG0NCiAgMzQyLjI1MDAgMTIwLjAwMDAgTA0KUw0KVQ0KdQ0KICAzNDIuMjUwMCAx MjAuMDAwMCBtDQogIDM0Mi43NTAwIDEyMC4yNTAwIEwNClMNClUNCnUNCiAgMzQyLjc1MDAg MTIwLjI1MDAgbQ0KICAzNDMuNTAwMCAxMjAuMjUwMCBMDQpTDQpVDQp1DQogIDM0My41MDAw IDEyMC4yNTAwIG0NCiAgMzQ0LjAwMDAgMTIwLjUwMDAgTA0KUw0KVQ0KdQ0KICAzNDQuMDAw MCAxMjAuNTAwMCBtDQogIDM0NC41MDAwIDEyMC41MDAwIEwNClMNClUNCnUNCiAgMzQ0LjUw MDAgMTIwLjUwMDAgbQ0KICAzNDUuMjUwMCAxMjAuNTAwMCBMDQpTDQpVDQp1DQogIDM0NS4y NTAwIDEyMC41MDAwIG0NCiAgMzQ1Ljc1MDAgMTIwLjI1MDAgTA0KUw0KVQ0KdQ0KICAzNDUu NzUwMCAxMjAuMjUwMCBtDQogIDM0Ni41MDAwIDEyMC4yNTAwIEwNClMNClUNCnUNCiAgMzQ2 LjUwMDAgMTIwLjI1MDAgbQ0KICAzNDcuMjUwMCAxMjAuMDAwMCBMDQpTDQpVDQp1DQogIDM0 Ny4yNTAwIDEyMC4wMDAwIG0NCiAgMzQ3Ljc1MDAgMTIwLjAwMDAgTA0KUw0KVQ0KdQ0KICAz NDcuNzUwMCAxMjAuMDAwMCBtDQogIDM0OC41MDAwIDEyMC4wMDAwIEwNClMNClUNCnUNCiAg MzQ4LjUwMDAgMTIwLjAwMDAgbQ0KICAzNDkuMjUwMCAxMTkuNzUwMCBMDQpTDQpVDQp1DQog IDM0OS4yNTAwIDExOS43NTAwIG0NCiAgMzQ5Ljc1MDAgMTE5LjUwMDAgTA0KUw0KVQ0KdQ0K ICAzNDkuNzUwMCAxMTkuNTAwMCBtDQogIDM1MC41MDAwIDExOS41MDAwIEwNClMNClUNCnUN CiAgMzUwLjUwMDAgMTE5LjUwMDAgbQ0KICAzNTAuNzUwMCAxMTkuNTAwMCBMDQpTDQpVDQp1 DQogIDM1MC43NTAwIDExOS41MDAwIG0NCiAgMzUxLjUwMDAgMTE5LjI1MDAgTA0KUw0KVQ0K dQ0KICAzNTEuNTAwMCAxMTkuMjUwMCBtDQogIDM1MS43NTAwIDExOS4yNTAwIEwNClMNClUN CnUNCiAgMzUxLjc1MDAgMTE5LjI1MDAgbQ0KICAzNTIuMjUwMCAxMTkuNTAwMCBMDQpTDQpV DQp1DQogIDM1Mi4yNTAwIDExOS41MDAwIG0NCiAgMzUyLjUwMDAgMTE5LjUwMDAgTA0KUw0K VQ0KdQ0KICAzNTIuNTAwMCAxMTkuNTAwMCBtDQogIDM1Mi43NTAwIDExOS41MDAwIEwNClMN ClUNCnUNCiAgMzUyLjc1MDAgMTE5LjUwMDAgbQ0KICAzNTMuMDAwMCAxMjAuMDAwMCBMDQpT DQpVDQp1DQogIDM1My4wMDAwIDEyMC4wMDAwIG0NCiAgMzUzLjI1MDAgMTIwLjAwMDAgTA0K Uw0KVQ0KdQ0KICAzNTMuMjUwMCAxMjAuMDAwMCBtDQogIDM1My41MDAwIDEyMC41MDAwIEwN ClMNClUNCnUNCiAgMzUzLjUwMDAgMTIwLjUwMDAgbQ0KICAzNTMuNzUwMCAxMjAuNzUwMCBM DQpTDQpVDQp1DQogIDM1My43NTAwIDEyMC43NTAwIG0NCiAgMzU0LjAwMDAgMTIxLjAwMDAg TA0KUw0KVQ0KdQ0KICAzODIuMjUwMCAxMjEuMDAwMCBtDQogIDM4Mi41MDAwIDEyMC41MDAw IEwNClMNClUNCnUNCiAgMzgyLjUwMDAgMTIwLjUwMDAgbQ0KICAzODIuNzUwMCAxMjAuMDAw MCBMDQpTDQpVDQp1DQogIDM4Mi43NTAwIDEyMC4wMDAwIG0NCiAgMzgyLjc1MDAgMTE5LjUw MDAgTA0KUw0KVQ0KdQ0KICAzODIuNzUwMCAxMTkuNTAwMCBtDQogIDM4My4wMDAwIDExOS4w MDAwIEwNClMNClUNCnUNCiAgMzgzLjAwMDAgMTE5LjAwMDAgbQ0KICAzODMuMDAwMCAxMTgu NTAwMCBMDQpTDQpVDQp1DQogIDM4My4wMDAwIDExOC41MDAwIG0NCiAgMzgzLjAwMDAgMTE4 LjAwMDAgTA0KUw0KVQ0KdQ0KICAzODMuMDAwMCAxMTcuNTAwMCBtDQogIDM4My4wMDAwIDEx OC4wMDAwIEwNClMNClUNCnUNCiAgMzgzLjAwMDAgMTE3LjAwMDAgbQ0KICAzODMuMDAwMCAx MTcuNTAwMCBMDQpTDQpVDQp1DQogIDM4My4wMDAwIDExNi41MDAwIG0NCiAgMzgzLjAwMDAg MTE3LjAwMDAgTA0KUw0KVQ0KdQ0KICAzODIuNzUwMCAxMTYuMDAwMCBtDQogIDM4My4wMDAw IDExNi41MDAwIEwNClMNClUNCnUNCiAgMzgyLjc1MDAgMTE1LjUwMDAgbQ0KICAzODIuNzUw MCAxMTYuMDAwMCBMDQpTDQpVDQp1DQogIDM4Mi43NTAwIDExNS4wMDAwIG0NCiAgMzgyLjc1 MDAgMTE1LjUwMDAgTA0KUw0KVQ0KdQ0KICAzODIuNzUwMCAxMTQuNTAwMCBtDQogIDM4Mi43 NTAwIDExNS4wMDAwIEwNClMNClUNCnUNCiAgMzgyLjUwMDAgMTEzLjc1MDAgbQ0KICAzODIu NzUwMCAxMTQuNTAwMCBMDQpTDQpVDQp1DQogIDM4Mi41MDAwIDExMy41MDAwIG0NCiAgMzgy LjUwMDAgMTEzLjc1MDAgTA0KUw0KVQ0KdQ0KICAzODIuMjUwMCAxMTMuMDAwMCBtDQogIDM4 Mi41MDAwIDExMy41MDAwIEwNClMNClUNCnUNCiAgMzgyLjI1MDAgMTEyLjc1MDAgbQ0KICAz ODIuMjUwMCAxMTMuMDAwMCBMDQpTDQpVDQp1DQogIDM4Mi4yNTAwIDExMi43NTAwIG0NCiAg MzgyLjUwMDAgMTEyLjUwMDAgTA0KUw0KVQ0KdQ0KICAzODIuNTAwMCAxMTIuNTAwMCBtDQog IDM4Mi41MDAwIDExMi4yNTAwIEwNClMNClUNCnUNCiAgMzgyLjUwMDAgMTEyLjI1MDAgbQ0K ICAzODIuNzUwMCAxMTIuMjUwMCBMDQpTDQpVDQp1DQogIDM4Mi43NTAwIDExMi4yNTAwIG0N CiAgMzgyLjc1MDAgMTEyLjI1MDAgTA0KUw0KVQ0KdQ0KICAzODIuNzUwMCAxMTIuMjUwMCBt DQogIDM4My4wMDAwIDExMi4wMDAwIEwNClMNClUNCnUNCiAgMzgzLjAwMDAgMTEyLjAwMDAg bQ0KICAzODMuMjUwMCAxMTIuMjUwMCBMDQpTDQpVDQp1DQogIDM4My4yNTAwIDExMi4yNTAw IG0NCiAgMzgzLjUwMDAgMTEyLjI1MDAgTA0KUw0KVQ0KdQ0KICAzODMuNTAwMCAxMTIuMjUw MCBtDQogIDM4My43NTAwIDExMi4yNTAwIEwNClMNClUNCnUNCiAgMzgzLjc1MDAgMTEyLjI1 MDAgbQ0KICAzODQuMjUwMCAxMTIuMjUwMCBMDQpTDQpVDQp1DQogIDM4NC4yNTAwIDExMi4y NTAwIG0NCiAgMzg0LjUwMDAgMTEyLjUwMDAgTA0KUw0KVQ0KdQ0KICAzODQuNTAwMCAxMTIu NTAwMCBtDQogIDM4NC43NTAwIDExMi41MDAwIEwNClMNClUNCnUNCiAgMzg0Ljc1MDAgMTEy LjUwMDAgbQ0KICAzODUuMjUwMCAxMTIuNTAwMCBMDQpTDQpVDQp1DQogIDM4NS4yNTAwIDEx Mi41MDAwIG0NCiAgMzg1LjUwMDAgMTEyLjUwMDAgTA0KUw0KVQ0KdQ0KICAzODUuNTAwMCAx MTIuNTAwMCBtDQogIDM4NS43NTAwIDExMi41MDAwIEwNClMNClUNCnUNCiAgMzg1Ljc1MDAg MTEyLjUwMDAgbQ0KICAzODYuMjUwMCAxMTIuNTAwMCBMDQpTDQpVDQp1DQogIDM4Ni4yNTAw IDExMi41MDAwIG0NCiAgMzg2LjUwMDAgMTEyLjUwMDAgTA0KUw0KVQ0KdQ0KICAzODYuNTAw MCAxMTIuNTAwMCBtDQogIDM4Ni43NTAwIDExMi41MDAwIEwNClMNClUNCnUNCiAgMzg2Ljc1 MDAgMTEyLjUwMDAgbQ0KICAzODcuMjUwMCAxMTIuNTAwMCBMDQpTDQpVDQp1DQogIDM4Ny4y NTAwIDExMi41MDAwIG0NCiAgMzg3LjUwMDAgMTEyLjUwMDAgTA0KUw0KVQ0KdQ0KICAzODcu NTAwMCAxMTIuNTAwMCBtDQogIDM4Ny43NTAwIDExMi4yNTAwIEwNClMNClUNCnUNCiAgMzg3 Ljc1MDAgMTEyLjI1MDAgbQ0KICAzODguMDAwMCAxMTIuMjUwMCBMDQpTDQpVDQp1DQogIDM4 OC4wMDAwIDExMi4yNTAwIG0NCiAgMzg4LjI1MDAgMTEyLjAwMDAgTA0KUw0KVQ0KdQ0KICAz ODguMjUwMCAxMTIuMDAwMCBtDQogIDM4OC43NTAwIDExMi4wMDAwIEwNClMNClUNCnUNCiAg Mzg4Ljc1MDAgMTEyLjAwMDAgbQ0KICAzODguNzUwMCAxMTEuNzUwMCBMDQpTDQpVDQp1DQog IDM4OC43NTAwIDExMS43NTAwIG0NCiAgMzg5LjI1MDAgMTExLjUwMDAgTA0KUw0KVQ0KdQ0K ICAzODkuMjUwMCAxMTEuNTAwMCBtDQogIDM4OS4yNTAwIDExMS4wMDAwIEwNClMNClUNCnUN CiAgMzg5LjI1MDAgMTExLjAwMDAgbQ0KICAzODkuNTAwMCAxMTEuMDAwMCBMDQpTDQpVDQp1 DQogIDM4OS41MDAwIDExMS4wMDAwIG0NCiAgMzg5Ljc1MDAgMTEwLjUwMDAgTA0KUw0KVQ0K dQ0KICAzODkuNzUwMCAxMTAuNTAwMCBtDQogIDM4OS43NTAwIDExMC4yNTAwIEwNClMNClUN CnUNCiAgMzg5Ljc1MDAgMTEwLjI1MDAgbQ0KICAzOTAuMDAwMCAxMDkuNzUwMCBMDQpTDQpV DQp1DQogIDM5MC4wMDAwIDEwOS43NTAwIG0NCiAgMzkwLjAwMDAgMTA5LjUwMDAgTA0KUw0K VQ0KdQ0KICAzOTAuMDAwMCAxMDkuNTAwMCBtDQogIDM5MC4wMDAwIDEwOS4yNTAwIEwNClMN ClUNCnUNCiAgMzkwLjAwMDAgMTA5LjI1MDAgbQ0KICAzOTAuMDAwMCAxMDguNzUwMCBMDQpT DQpVDQp1DQogIDM5MC4wMDAwIDEwOC43NTAwIG0NCiAgMzkwLjAwMDAgMTA4LjI1MDAgTA0K Uw0KVQ0KdQ0KICAzOTAuMDAwMCAxMDguMDAwMCBtDQogIDM5MC4wMDAwIDEwOC4yNTAwIEwN ClMNClUNCnUNCiAgMzkwLjAwMDAgMTA3LjUwMDAgbQ0KICAzOTAuMDAwMCAxMDguMDAwMCBM DQpTDQpVDQp1DQogIDM5MC4wMDAwIDEwNy4wMDAwIG0NCiAgMzkwLjAwMDAgMTA3LjUwMDAg TA0KUw0KVQ0KdQ0KICAzOTAuMDAwMCAxMDcuMDAwMCBtDQogIDM5MC4wMDAwIDEwNi43NTAw IEwNClMNClUNCnUNCiAgMzkwLjAwMDAgMTA2Ljc1MDAgbQ0KICAzOTAuMjUwMCAxMDYuNTAw MCBMDQpTDQpVDQp1DQogIDM5MC4yNTAwIDEwNi41MDAwIG0NCiAgMzkwLjI1MDAgMTA2LjI1 MDAgTA0KUw0KVQ0KdQ0KICAzOTAuMjUwMCAxMDYuMjUwMCBtDQogIDM5MC41MDAwIDEwNS43 NTAwIEwNClMNClUNCnUNCiAgMzkwLjc1MDAgMTA1Ljc1MDAgbQ0KICAzOTAuNTAwMCAxMDUu NzUwMCBMDQpTDQpVDQp1DQogIDM5MS4wMDAwIDEwNS41MDAwIG0NCiAgMzkwLjc1MDAgMTA1 Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzOTEuMjUwMCAxMDUuMjUwMCBtDQogIDM5MS4wMDAwIDEw NS41MDAwIEwNClMNClUNCnUNCiAgMzkxLjc1MDAgMTA1LjAwMDAgbQ0KICAzOTEuMjUwMCAx MDUuMjUwMCBMDQpTDQpVDQp1DQogIDM5Mi4wMDAwIDEwNC43NTAwIG0NCiAgMzkxLjc1MDAg MTA1LjAwMDAgTA0KUw0KVQ0KdQ0KICAzOTIuNTAwMCAxMDQuNzUwMCBtDQogIDM5Mi4wMDAw IDEwNC43NTAwIEwNClMNClUNCnUNCiAgMzkzLjAwMDAgMTA0Ljc1MDAgbQ0KICAzOTIuNTAw MCAxMDQuNzUwMCBMDQpTDQpVDQp1DQogIDM5My41MDAwIDEwNC41MDAwIG0NCiAgMzkzLjAw MDAgMTA0Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzOTQuMDAwMCAxMDQuMjUwMCBtDQogIDM5My41 MDAwIDEwNC41MDAwIEwNClMNClUNCnUNCiAgMzk0LjUwMDAgMTA0LjAwMDAgbQ0KICAzOTQu MDAwMCAxMDQuMjUwMCBMDQpTDQpVDQp1DQogIDM5NS4wMDAwIDEwMy43NTAwIG0NCiAgMzk0 LjUwMDAgMTA0LjAwMDAgTA0KUw0KVQ0KdQ0KICAzOTUuNTAwMCAxMDMuNTAwMCBtDQogIDM5 NS4wMDAwIDEwMy43NTAwIEwNClMNClUNCnUNCiAgMzk2LjAwMDAgMTAzLjI1MDAgbQ0KICAz OTUuNTAwMCAxMDMuNTAwMCBMDQpTDQpVDQp1DQogIDM5Ni4yNTAwIDEwMy4wMDAwIG0NCiAg Mzk2LjAwMDAgMTAzLjI1MDAgTA0KUw0KVQ0KdQ0KICAzOTcuMDAwMCAxMDIuNTAwMCBtDQog IDM5Ni4yNTAwIDEwMy4wMDAwIEwNClMNClUNCnUNCiAgMzk3LjI1MDAgMTAyLjI1MDAgbQ0K ICAzOTcuMDAwMCAxMDIuNTAwMCBMDQpTDQpVDQp1DQogIDM5Ny41MDAwIDEwMi4wMDAwIG0N CiAgMzk3LjI1MDAgMTAyLjI1MDAgTA0KUw0KVQ0KdQ0KICAzOTguMDAwMCAxMDEuNTAwMCBt DQogIDM5Ny41MDAwIDEwMi4wMDAwIEwNClMNClUNCnUNCiAgMzk4LjI1MDAgMTAxLjI1MDAg bQ0KICAzOTguMDAwMCAxMDEuNTAwMCBMDQpTDQpVDQp1DQogIDM5OC41MDAwIDEwMC43NTAw IG0NCiAgMzk4LjI1MDAgMTAxLjI1MDAgTA0KUw0KVQ0KdQ0KICAzOTguNzUwMCAxMDAuMjUw MCBtDQogIDM5OC41MDAwIDEwMC43NTAwIEwNClMNClUNCnUNCiAgMzk5LjAwMDAgMTAwLjAw MDAgbQ0KICAzOTguNzUwMCAxMDAuMjUwMCBMDQpTDQpVDQp1DQogIDM5OS4yNTAwIDk5LjUw MDAgbQ0KICAzOTkuMDAwMCAxMDAuMDAwMCBMDQpTDQpVDQp1DQogIDM5OS41MDAwIDk5LjAw MDAgbQ0KICAzOTkuMjUwMCA5OS41MDAwIEwNClMNClUNCnUNCiAgMzk5LjUwMDAgOTguNTAw MCBtDQogIDM5OS41MDAwIDk5LjAwMDAgTA0KUw0KVQ0KdQ0KICAzOTkuNzUwMCA5OC4yNTAw IG0NCiAgMzk5LjUwMDAgOTguNTAwMCBMDQpTDQpVDQp1DQogIDM5OS43NTAwIDk3Ljc1MDAg bQ0KICAzOTkuNzUwMCA5OC4yNTAwIEwNClMNClUNCnUNCiAgMzk5Ljc1MDAgOTcuMjUwMCBt DQogIDM5OS43NTAwIDk3Ljc1MDAgTA0KUw0KVQ0KdQ0KICA0MDAuMDAwMCA5Ni43NTAwIG0N CiAgMzk5Ljc1MDAgOTcuMjUwMCBMDQpTDQpVDQp1DQogIDQwMC4wMDAwIDk2LjI1MDAgbQ0K ICA0MDAuMDAwMCA5Ni43NTAwIEwNClMNClUNCnUNCiAgMzk5Ljc1MDAgOTUuNzUwMCBtDQog IDQwMC4wMDAwIDk2LjI1MDAgTA0KUw0KVQ0KdQ0KICAzOTkuNzUwMCA5NS41MDAwIG0NCiAg Mzk5Ljc1MDAgOTUuNzUwMCBMDQpTDQpVDQp1DQogIDM5OS43NTAwIDk0Ljc1MDAgbQ0KICAz OTkuNzUwMCA5NS41MDAwIEwNClMNClUNCnUNCiAgMzk5LjUwMDAgOTQuNTAwMCBtDQogIDM5 OS43NTAwIDk0Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzOTkuMjUwMCA5NC4wMDAwIG0NCiAgMzk5 LjUwMDAgOTQuNTAwMCBMDQpTDQpVDQp1DQogIDM5OS4yNTAwIDkzLjUwMDAgbQ0KICAzOTku MjUwMCA5NC4wMDAwIEwNClMNClUNCnUNCiAgMzk5LjAwMDAgOTMuMDAwMCBtDQogIDM5OS4y NTAwIDkzLjUwMDAgTA0KUw0KVQ0KdQ0KICAzOTguNzUwMCA5Mi41MDAwIG0NCiAgMzk5LjAw MDAgOTMuMDAwMCBMDQpTDQpVDQp1DQogIDM5OC41MDAwIDkyLjAwMDAgbQ0KICAzOTguNzUw MCA5Mi41MDAwIEwNClMNClUNCnUNCiAgMzk4LjI1MDAgOTEuNzUwMCBtDQogIDM5OC41MDAw IDkyLjAwMDAgTA0KUw0KVQ0KdQ0KICAzOTguMjUwMCA5MS4yNTAwIG0NCiAgMzk4LjI1MDAg OTEuNzUwMCBMDQpTDQpVDQp1DQogIDM5Ny43NTAwIDkxLjI1MDAgbQ0KICAzOTguMjUwMCA5 MS4yNTAwIEwNClMNClUNCnUNCiAgMzk3LjUwMDAgOTAuNzUwMCBtDQogIDM5Ny43NTAwIDkx LjI1MDAgTA0KUw0KVQ0KdQ0KICAzOTcuMjUwMCA5MC41MDAwIG0NCiAgMzk3LjUwMDAgOTAu NzUwMCBMDQpTDQpVDQp1DQogIDM5Ny4wMDAwIDkwLjI1MDAgbQ0KICAzOTcuMjUwMCA5MC41 MDAwIEwNClMNClUNCnUNCiAgMzk2Ljc1MDAgOTAuMDAwMCBtDQogIDM5Ny4wMDAwIDkwLjI1 MDAgTA0KUw0KVQ0KdQ0KICAzOTYuNTAwMCA4OS43NTAwIG0NCiAgMzk2Ljc1MDAgOTAuMDAw MCBMDQpTDQpVDQp1DQogIDM5Ni4yNTAwIDg5LjUwMDAgbQ0KICAzOTYuNTAwMCA4OS43NTAw IEwNClMNClUNCnUNCiAgMzk1Ljc1MDAgODkuNTAwMCBtDQogIDM5Ni4yNTAwIDg5LjUwMDAg TA0KUw0KVQ0KdQ0KICAzOTUuNTAwMCA4OS4yNTAwIG0NCiAgMzk1Ljc1MDAgODkuNTAwMCBM DQpTDQpVDQp1DQogIDM5NS4wMDAwIDg5LjAwMDAgbQ0KICAzOTUuNTAwMCA4OS4yNTAwIEwN ClMNClUNCnUNCiAgMzk0Ljc1MDAgODkuMDAwMCBtDQogIDM5NS4wMDAwIDg5LjAwMDAgTA0K Uw0KVQ0KdQ0KICAzOTQuMjUwMCA4OC43NTAwIG0NCiAgMzk0Ljc1MDAgODkuMDAwMCBMDQpT DQpVDQp1DQogIDM5NC4wMDAwIDg4LjUwMDAgbQ0KICAzOTQuMjUwMCA4OC43NTAwIEwNClMN ClUNCnUNCiAgMzkzLjc1MDAgODguMjUwMCBtDQogIDM5NC4wMDAwIDg4LjUwMDAgTA0KUw0K VQ0KdQ0KICAzOTMuMjUwMCA4OC4yNTAwIG0NCiAgMzkzLjc1MDAgODguMjUwMCBMDQpTDQpV DQp1DQogIDM5My4wMDAwIDg4LjAwMDAgbQ0KICAzOTMuMjUwMCA4OC4yNTAwIEwNClMNClUN CnUNCiAgMzkyLjc1MDAgODcuNzUwMCBtDQogIDM5My4wMDAwIDg4LjAwMDAgTA0KUw0KVQ0K dQ0KICAzOTIuMjUwMCA4Ny43NTAwIG0NCiAgMzkyLjc1MDAgODcuNzUwMCBMDQpTDQpVDQp1 DQogIDM5Mi4wMDAwIDg3LjUwMDAgbQ0KICAzOTIuMjUwMCA4Ny43NTAwIEwNClMNClUNCnUN CiAgMzkxLjc1MDAgODcuMjUwMCBtDQogIDM5Mi4wMDAwIDg3LjUwMDAgTA0KUw0KVQ0KdQ0K ICAzOTEuNTAwMCA4Ny4wMDAwIG0NCiAgMzkxLjc1MDAgODcuMjUwMCBMDQpTDQpVDQp1DQog IDM5MS4yNTAwIDg2Ljc1MDAgbQ0KICAzOTEuNTAwMCA4Ny4wMDAwIEwNClMNClUNCnUNCiAg MzkxLjAwMDAgODYuNTAwMCBtDQogIDM5MS4yNTAwIDg2Ljc1MDAgTA0KUw0KVQ0KdQ0KICAz OTAuNzUwMCA4Ni4wMDAwIG0NCiAgMzkxLjAwMDAgODYuNTAwMCBMDQpTDQpVDQp1DQogIDM5 MC41MDAwIDg1Ljc1MDAgbQ0KICAzOTAuNzUwMCA4Ni4wMDAwIEwNClMNClUNCnUNCiAgMzkw LjI1MDAgODUuMjUwMCBtDQogIDM5MC41MDAwIDg1Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzOTAu MDAwMCA4NC43NTAwIG0NCiAgMzkwLjI1MDAgODUuMjUwMCBMDQpTDQpVDQp1DQogIDM4OS43 NTAwIDg0LjI1MDAgbQ0KICAzOTAuMDAwMCA4NC43NTAwIEwNClMNClUNCnUNCiAgMzg5LjI1 MDAgODMuNzUwMCBtDQogIDM4OS43NTAwIDg0LjI1MDAgTA0KUw0KVQ0KdQ0KICAzODkuMDAw MCA4My4yNTAwIG0NCiAgMzg5LjI1MDAgODMuNzUwMCBMDQpTDQpVDQp1DQogIDM4OC43NTAw IDgzLjAwMDAgbQ0KICAzODkuMDAwMCA4My4yNTAwIEwNClMNClUNCnUNCiAgMzg4LjI1MDAg ODIuNTAwMCBtDQogIDM4OC43NTAwIDgzLjAwMDAgTA0KUw0KVQ0KdQ0KICAzODguMDAwMCA4 Mi4yNTAwIG0NCiAgMzg4LjI1MDAgODIuNTAwMCBMDQpTDQpVDQp1DQogIDM4Ny41MDAwIDgx Ljc1MDAgbQ0KICAzODguMDAwMCA4Mi4yNTAwIEwNClMNClUNCnUNCiAgMzg3LjI1MDAgODEu MjUwMCBtDQogIDM4Ny41MDAwIDgxLjc1MDAgTA0KUw0KVQ0KdQ0KICAzODYuNzUwMCA4MS4w MDAwIG0NCiAgMzg3LjI1MDAgODEuMjUwMCBMDQpTDQpVDQp1DQogIDM4Ni4yNTAwIDgwLjc1 MDAgbQ0KICAzODYuNzUwMCA4MS4wMDAwIEwNClMNClUNCnUNCiAgMzg1Ljc1MDAgODAuNTAw MCBtDQogIDM4Ni4yNTAwIDgwLjc1MDAgTA0KUw0KVQ0KdQ0KICAzODUuMjUwMCA4MC4yNTAw IG0NCiAgMzg1Ljc1MDAgODAuNTAwMCBMDQpTDQpVDQp1DQogIDM4NC41MDAwIDgwLjI1MDAg bQ0KICAzODUuMjUwMCA4MC4yNTAwIEwNClMNClUNCnUNCiAgMzg0LjI1MDAgODAuMDAwMCBt DQogIDM4NC41MDAwIDgwLjI1MDAgTA0KUw0KVQ0KdQ0KICAzODMuNzUwMCA3OS43NTAwIG0N CiAgMzg0LjI1MDAgODAuMDAwMCBMDQpTDQpVDQp1DQogIDM4My4yNTAwIDc5Ljc1MDAgbQ0K ICAzODMuNzUwMCA3OS43NTAwIEwNClMNClUNCnUNCiAgMzgyLjc1MDAgNzkuNTAwMCBtDQog IDM4My4yNTAwIDc5Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzODIuMDAwMCA3OS41MDAwIG0NCiAg MzgyLjc1MDAgNzkuNTAwMCBMDQpTDQpVDQp1DQogIDM4MS41MDAwIDc5LjUwMDAgbQ0KICAz ODIuMDAwMCA3OS41MDAwIEwNClMNClUNCnUNCiAgMzgxLjAwMDAgNzkuNTAwMCBtDQogIDM4 MS41MDAwIDc5LjUwMDAgTA0KUw0KVQ0KdQ0KICAzODAuNTAwMCA3OS41MDAwIG0NCiAgMzgx LjAwMDAgNzkuNTAwMCBMDQpTDQpVDQp1DQogIDM4MC4wMDAwIDc5LjUwMDAgbQ0KICAzODAu NTAwMCA3OS41MDAwIEwNClMNClUNCnUNCiAgMzc5Ljc1MDAgNzkuNTAwMCBtDQogIDM4MC4w MDAwIDc5LjUwMDAgTA0KUw0KVQ0KdQ0KICAzNzkuNTAwMCA3OS41MDAwIG0NCiAgMzc5Ljc1 MDAgNzkuNTAwMCBMDQpTDQpVDQp1DQogIDM3OS4wMDAwIDc5LjUwMDAgbQ0KICAzNzkuNTAw MCA3OS41MDAwIEwNClMNClUNCnUNCiAgMzc4Ljc1MDAgNzkuNTAwMCBtDQogIDM3OS4wMDAw IDc5LjUwMDAgTA0KUw0KVQ0KdQ0KICAzNzguMjUwMCA3OS43NTAwIG0NCiAgMzc4Ljc1MDAg NzkuNTAwMCBMDQpTDQpVDQp1DQogIDM3Ny43NTAwIDc5Ljc1MDAgbQ0KICAzNzguMjUwMCA3 OS43NTAwIEwNClMNClUNCnUNCiAgMzc3LjI1MDAgODAuMDAwMCBtDQogIDM3Ny43NTAwIDc5 Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzNzcuMDAwMCA4MC4wMDAwIG0NCiAgMzc3LjI1MDAgODAu MDAwMCBMDQpTDQpVDQp1DQogIDM3Ni41MDAwIDgwLjAwMDAgbQ0KICAzNzcuMDAwMCA4MC4w MDAwIEwNClMNClUNCnUNCiAgMzc2LjAwMDAgODAuMjUwMCBtDQogIDM3Ni41MDAwIDgwLjAw MDAgTA0KUw0KVQ0KdQ0KICAzNzUuNzUwMCA4MC4yNTAwIG0NCiAgMzc2LjAwMDAgODAuMjUw MCBMDQpTDQpVDQp1DQogIDM3NS4wMDAwIDgwLjUwMDAgbQ0KICAzNzUuNzUwMCA4MC4yNTAw IEwNClMNClUNCnUNCiAgMzc0Ljc1MDAgODAuNTAwMCBtDQogIDM3NS4wMDAwIDgwLjUwMDAg TA0KUw0KVQ0KdQ0KICAzNzQuMjUwMCA4MC43NTAwIG0NCiAgMzc0Ljc1MDAgODAuNTAwMCBM DQpTDQpVDQp1DQogIDM3My43NTAwIDgxLjAwMDAgbQ0KICAzNzQuMjUwMCA4MC43NTAwIEwN ClMNClUNCnUNCiAgMzczLjI1MDAgODEuMjUwMCBtDQogIDM3My43NTAwIDgxLjAwMDAgTA0K Uw0KVQ0KdQ0KICAzNzMuMDAwMCA4MS4yNTAwIG0NCiAgMzczLjI1MDAgODEuMDAwMCBMDQpT DQpVDQp1DQogIDM3Mi41MDAwIDgxLjUwMDAgbQ0KICAzNzMuMDAwMCA4MS4yNTAwIEwNClMN ClUNCnUNCiAgMzcyLjAwMDAgODEuNTAwMCBtDQogIDM3Mi41MDAwIDgxLjUwMDAgTA0KUw0K VQ0KdQ0KICAzNzEuNzUwMCA4MS41MDAwIG0NCiAgMzcyLjAwMDAgODEuNTAwMCBMDQpTDQpV DQp1DQogIDM3MS41MDAwIDgxLjUwMDAgbQ0KICAzNzEuNzUwMCA4MS41MDAwIEwNClMNClUN CnUNCiAgMzcxLjAwMDAgODEuNTAwMCBtDQogIDM3MS41MDAwIDgxLjUwMDAgTA0KUw0KVQ0K dQ0KICAzNzAuNzUwMCA4MS41MDAwIG0NCiAgMzcxLjAwMDAgODEuNTAwMCBMDQpTDQpVDQp1 DQogIDM3MC41MDAwIDgxLjI1MDAgbQ0KICAzNzAuNzUwMCA4MS41MDAwIEwNClMNClUNCnUN CiAgMzcwLjI1MDAgODEuMDAwMCBtDQogIDM3MC41MDAwIDgxLjI1MDAgTA0KUw0KVQ0KdQ0K ICAzNzAuMDAwMCA4MS4wMDAwIG0NCiAgMzcwLjI1MDAgODEuMDAwMCBMDQpTDQpVDQp1DQog IDM3MC4wMDAwIDgwLjUwMDAgbQ0KICAzNzAuMDAwMCA4MS4wMDAwIEwNClMNClUNCnUNCiAg MzY5Ljc1MDAgODAuMjUwMCBtDQogIDM3MC4wMDAwIDgwLjUwMDAgTA0KUw0KVQ0KdQ0KICAz NjkuNTAwMCA4MC4wMDAwIG0NCiAgMzY5Ljc1MDAgODAuMjUwMCBMDQpTDQpVDQp1DQogIDM2 OS4yNTAwIDc5Ljc1MDAgbQ0KICAzNjkuNTAwMCA4MC4wMDAwIEwNClMNClUNCnUNCiAgMzY5 LjAwMDAgNzkuNTAwMCBtDQogIDM2OS4yNTAwIDc5Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzNjgu NzUwMCA3OS4yNTAwIG0NCiAgMzY5LjAwMDAgNzkuNTAwMCBMDQpTDQpVDQp1DQogIDM2OC4y NTAwIDc5LjAwMDAgbQ0KICAzNjguNzUwMCA3OS4yNTAwIEwNClMNClUNCnUNCiAgMzY4LjAw MDAgMTIzLjAwMDAgbQ0KICAzNjguNTAwMCAxMjMuMjUwMCBMDQpTDQpVDQp1DQogIDM2Mi41 MDAwIDEyMy43NTAwIG0NCiAgMzYzLjAwMDAgMTIzLjc1MDAgTA0KUw0KVQ0KdQ0KICAzNjMu MDAwMCAxMjMuNzUwMCBtDQogIDM2My41MDAwIDEyMy41MDAwIEwNClMNClUNCnUNCiAgMzYz LjUwMDAgMTIzLjUwMDAgbQ0KICAzNjQuMDAwMCAxMjMuMjUwMCBMDQpTDQpVDQp1DQogIDM2 NC4wMDAwIDEyMy4yNTAwIG0NCiAgMzY0LjUwMDAgMTIzLjAwMDAgTA0KUw0KVQ0KdQ0KICAz NjQuNTAwMCAxMjMuMDAwMCBtDQogIDM2NS4wMDAwIDEyMy4wMDAwIEwNClMNClUNCnUNCiAg MzY1LjAwMDAgMTIzLjAwMDAgbQ0KICAzNjUuNTAwMCAxMjIuNzUwMCBMDQpTDQpVDQp1DQog IDM2NS41MDAwIDEyMi43NTAwIG0NCiAgMzY2LjAwMDAgMTIyLjc1MDAgTA0KUw0KVQ0KdQ0K ICAzNjYuMDAwMCAxMjIuNzUwMCBtDQogIDM2Ni41MDAwIDEyMi43NTAwIEwNClMNClUNCnUN CiAgMzY2LjUwMDAgMTIyLjc1MDAgbQ0KICAzNjcuMDAwMCAxMjIuNzUwMCBMDQpTDQpVDQp1 DQogIDM2Ny4wMDAwIDEyMi43NTAwIG0NCiAgMzY3LjUwMDAgMTIyLjc1MDAgTA0KUw0KVQ0K dQ0KICAzNjcuNTAwMCAxMjIuNzUwMCBtDQogIDM2OC4wMDAwIDEyMy4wMDAwIEwNClMNClUN CnUNCiAgMzU0LjUwMDAgMTIxLjUwMDAgbQ0KICAzNTQuNzUwMCAxMjEuNzUwMCBMDQpTDQpV DQp1DQogIDM1NC43NTAwIDEyMS43NTAwIG0NCiAgMzU1LjI1MDAgMTIyLjAwMDAgTA0KUw0K VQ0KdQ0KICAzNTUuMjUwMCAxMjIuMDAwMCBtDQogIDM1NS43NTAwIDEyMi41MDAwIEwNClMN ClUNCnUNCiAgMzU1Ljc1MDAgMTIyLjUwMDAgbQ0KICAzNTYuMjUwMCAxMjIuNzUwMCBMDQpT DQpVDQp1DQogIDM1Ni4yNTAwIDEyMi43NTAwIG0NCiAgMzU2Ljc1MDAgMTIzLjAwMDAgTA0K Uw0KVQ0KdQ0KICAzNTYuNzUwMCAxMjMuMDAwMCBtDQogIDM1Ny41MDAwIDEyMy4yNTAwIEwN ClMNClUNCnUNCiAgMzU3LjUwMDAgMTIzLjI1MDAgbQ0KICAzNTguMDAwMCAxMjMuNzUwMCBM DQpTDQpVDQp1DQogIDM1OC4wMDAwIDEyMy43NTAwIG0NCiAgMzU4LjUwMDAgMTIzLjc1MDAg TA0KUw0KVQ0KdQ0KICAzNTguNTAwMCAxMjMuNzUwMCBtDQogIDM1OS4yNTAwIDEyNC4wMDAw IEwNClMNClUNCnUNCiAgMzU5LjI1MDAgMTI0LjAwMDAgbQ0KICAzNTkuNzUwMCAxMjQuMDAw MCBMDQpTDQpVDQp1DQogIDM1OS43NTAwIDEyNC4wMDAwIG0NCiAgMzYwLjUwMDAgMTI0LjAw MDAgTA0KUw0KVQ0KdQ0KICAzNjAuNTAwMCAxMjQuMDAwMCBtDQogIDM2MS4wMDAwIDEyNC4w MDAwIEwNClMNClUNCnUNCiAgMzYxLjAwMDAgMTI0LjAwMDAgbQ0KICAzNjEuNTAwMCAxMjQu MDAwMCBMDQpTDQpVDQp1DQogIDM2MS41MDAwIDEyNC4wMDAwIG0NCiAgMzYyLjAwMDAgMTI0 LjAwMDAgTA0KUw0KVQ0KdQ0KICAzNjIuMDAwMCAxMjQuMDAwMCBtDQogIDM2Mi41MDAwIDEy My43NTAwIEwNClMNClUNCnUNCiAgMzY4LjUwMDAgMTIzLjI1MDAgbQ0KICAzNjkuMDAwMCAx MjMuNTAwMCBMDQpTDQpVDQp1DQogIDM2OS4wMDAwIDEyMy41MDAwIG0NCiAgMzY5LjUwMDAg MTIzLjc1MDAgTA0KUw0KVQ0KdQ0KICAzNjkuNTAwMCAxMjMuNzUwMCBtDQogIDM3MC4yNTAw IDEyNC4wMDAwIEwNClMNClUNCnUNCiAgMzcwLjI1MDAgMTI0LjAwMDAgbQ0KICAzNzAuNzUw MCAxMjQuMjUwMCBMDQpTDQpVDQp1DQogIDM3MC43NTAwIDEyNC4yNTAwIG0NCiAgMzcxLjUw MDAgMTI0LjUwMDAgTA0KUw0KVQ0KdQ0KICAzNzEuNTAwMCAxMjQuNTAwMCBtDQogIDM3Mi4y NTAwIDEyNC43NTAwIEwNClMNClUNCnUNCiAgMzcyLjI1MDAgMTI0Ljc1MDAgbQ0KICAzNzMu MDAwMCAxMjQuNzUwMCBMDQpTDQpVDQp1DQogIDM3My4wMDAwIDEyNC43NTAwIG0NCiAgMzcz Ljc1MDAgMTI1LjAwMDAgTA0KUw0KVQ0KdQ0KICAzNzMuNzUwMCAxMjUuMDAwMCBtDQogIDM3 NC41MDAwIDEyNS4wMDAwIEwNClMNClUNCnUNCiAgMzc0LjUwMDAgMTI1LjAwMDAgbQ0KICAz NzUuMDAwMCAxMjUuMDAwMCBMDQpTDQpVDQp1DQogIDM3NS4wMDAwIDEyNS4wMDAwIG0NCiAg Mzc1Ljc1MDAgMTI1LjAwMDAgTA0KUw0KVQ0KdQ0KICAzNzUuNzUwMCAxMjUuMDAwMCBtDQog IDM3Ni41MDAwIDEyNS4wMDAwIEwNClMNClUNCnUNCiAgMzc2LjUwMDAgMTI1LjAwMDAgbQ0K ICAzNzcuMDAwMCAxMjUuMDAwMCBMDQpTDQpVDQp1DQogIDM3Ny4wMDAwIDEyNS4wMDAwIG0N CiAgMzc3Ljc1MDAgMTI0Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzNzcuNzUwMCAxMjQuNzUwMCBt DQogIDM3OC4yNTAwIDEyNC43NTAwIEwNClMNClUNCnUNCiAgMzc4LjI1MDAgMTI0Ljc1MDAg bQ0KICAzNzguNzUwMCAxMjQuNTAwMCBMDQpTDQpVDQp1DQogIDM3OC43NTAwIDEyNC41MDAw IG0NCiAgMzc5LjI1MDAgMTI0LjI1MDAgTA0KUw0KVQ0KdQ0KICAzNzkuMjUwMCAxMjQuMjUw MCBtDQogIDM3OS43NTAwIDEyNC4wMDAwIEwNClMNClUNCnUNCiAgMzc5Ljc1MDAgMTI0LjAw MDAgbQ0KICAzODAuMDAwMCAxMjMuNTAwMCBMDQpTDQpVDQp1DQogIDM4MC4wMDAwIDEyMy41 MDAwIG0NCiAgMzgwLjUwMDAgMTIzLjI1MDAgTA0KUw0KVQ0KdQ0KICAzODAuNTAwMCAxMjMu MjUwMCBtDQogIDM4MS4wMDAwIDEyMi43NTAwIEwNClMNClUNCnUNCiAgMzgxLjAwMDAgMTIy Ljc1MDAgbQ0KICAzODEuMjUwMCAxMjIuNTAwMCBMDQpTDQpVDQp1DQogIDM4MS4yNTAwIDEy Mi41MDAwIG0NCiAgMzgxLjUwMDAgMTIyLjI1MDAgTA0KUw0KVQ0KdQ0KICAzODEuNTAwMCAx MjIuMjUwMCBtDQogIDM4MS43NTAwIDEyMS43NTAwIEwNClMNClUNCnUNCiAgMzgxLjc1MDAg MTIxLjc1MDAgbQ0KICAzODIuMDAwMCAxMjEuMjUwMCBMDQpTDQpVDQp1DQoxLjUwMDAgdw0K MCBqDQogIDQ3My41MDAwIDcwLjc1MDAgbQ0KICA0NzMuNTAwMCA3NC4wMDAwIEwNCiAgNDg1 LjAwMDAgNzQuMDAwMCBMDQogIDQ4NS4wMDAwIDcwLjc1MDAgTA0KICA0ODUuMDAwMCA3MC43 NTAwIEwNCiAgNDg1LjAwMDAgNzAuNzUwMCBMDQpTDQpVDQp1DQoxIGoNCiAgNDc2LjUwMDAg NzEuMjUwMCBtDQogIDQ4Mi4wMDAwIDcxLjI1MDAgTA0KUw0KVQ0KdQ0KICA0NzkuMjUwMCA3 MS4yNTAwIG0NCiAgNDc5LjI1MDAgNjAuMDAwMCBMDQpTDQpVDQogIDAuMDAwIDAuMDAwIDAu MDAwIDAuMDAwIGsNCjAuMDAwMCB3DQogIDAuMDAwIDAuMDAwIDAuMDAwIDAuMDAwIGsNCiAg MC4wMDAgMC4wMDAgMC4wMDAgMC4wMDAgaw0KKnUNCiAgNDg3LjUwMDAgNDYuNTAwMCBtDQog IDQ4OC43NTAwIDQ2LjUwMDAgIDQ4OS41MDAwIDQ3Ljc1MDAgIDQ4OS41MDAwIDQ4Ljc1MDAg Qw0KICA0ODkuNTAwMCA1OC4yNTAwIEwNCiAgNDg5LjUwMDAgNTkuNTAwMCAgNDg4LjUwMDAg NjAuNzUwMCAgNDg3LjUwMDAgNjAuNTAwMCBDDQogIDQ3MC4wMDAwIDYwLjUwMDAgTA0KICA0 NjguNzUwMCA2MC41MDAwICA0NjguMDAwMCA1OS41MDAwICA0NjguMDAwMCA1OC4yNTAwIEMN CiAgNDY4LjAwMDAgNDguNzUwMCBMDQogIDQ2OC4wMDAwIDQ3Ljc1MDAgIDQ2OC43NTAwIDQ2 LjUwMDAgIDQ3MC4wMDAwIDQ2LjUwMDAgQw0KICA0ODcuNTAwMCA0Ni41MDAwIEwNCkINCipV DQp1DQoxLjUwMDAgdw0KMCBqDQogIDQzOS41MDAwIDk5LjUwMDAgbQ0KICA1MzguNzUwMCA5 OS41MDAwIEwNCiAgNTM4Ljc1MDAgMTMwLjc1MDAgTA0KUw0KVQ0KdQ0KICA0NzkuMjUwMCA3 NC4wMDAwIG0NCiAgNDc5LjI1MDAgOTkuNTAwMCBMDQpTDQpVDQp1DQogIDUxOS4wMDAwIDc0 LjAwMDAgbQ0KICA1MTkuMDAwMCA5OS41MDAwIEwNClMNClUNCiAgMC4wMDAgMC4wMDAgMC4w MDAgMC4wMDAgaw0KMC4wMDAwIHcNCiAgMC4wMDAgMC4wMDAgMC4wMDAgMC4wMDAgaw0KICAw LjAwMCAwLjAwMCAwLjAwMCAwLjAwMCBrDQoqdQ0KICA1MjcuMDAwMCA2MC4wMDAwIG0NCiAg NTI4LjI1MDAgNjAuMDAwMCAgNTI5LjI1MDAgNjEuMDAwMCAgNTI5LjI1MDAgNjIuMjUwMCBD DQogIDUyOS4yNTAwIDcxLjc1MDAgTA0KICA1MjkuMjUwMCA3My4wMDAwICA1MjguMjUwMCA3 NC4wMDAwICA1MjcuMDAwMCA3NC4wMDAwIEMNCiAgNTA5Ljc1MDAgNzQuMDAwMCBMDQogIDUw OC41MDAwIDc0LjAwMDAgIDUwNy41MDAwIDczLjAwMDAgIDUwNy41MDAwIDcxLjc1MDAgQw0K ICA1MDcuNTAwMCA2Mi4yNTAwIEwNCiAgNTA3LjUwMDAgNjEuMDAwMCAgNTA4LjUwMDAgNjAu MDAwMCAgNTA5Ljc1MDAgNjAuMDAwMCBDDQogIDUyNy4wMDAwIDYwLjAwMDAgTA0KQg0KKlUN CiAgMC4wMDAgMC4wMDAgMC4wMDAgMC4wMDAgaw0KICAwLjAwMCAwLjAwMCAwLjAwMCAwLjAw MCBrDQogIDAuMDAwIDAuMDAwIDAuMDAwIDAuMDAwIGsNCip1DQogIDU0Ny4wMDAwIDEzMS4w MDAwIG0NCiAgNTQ4LjI1MDAgMTMxLjAwMDAgIDU0OS4wMDAwIDEzMi4wMDAwICA1NDkuMDAw MCAxMzMuMjUwMCBDDQogIDU0OS4wMDAwIDE0Mi43NTAwIEwNCiAgNTQ5LjAwMDAgMTQ0LjAw MDAgIDU0OC4wMDAwIDE0NS4wMDAwICA1NDcuMDAwMCAxNDUuMDAwMCBDDQogIDUyOS41MDAw IDE0NS4wMDAwIEwNCiAgNTI4LjUwMDAgMTQ1LjAwMDAgIDUyNy41MDAwIDE0My43NTAwICA1 MjcuNTAwMCAxNDIuNzUwMCBDDQogIDUyNy41MDAwIDEzMy4yNTAwIEwNCiAgNTI3LjUwMDAg MTMyLjAwMDAgIDUyOC41MDAwIDEzMS4wMDAwICA1MjkuNTAwMCAxMzEuMDAwMCBDDQogIDU0 Ny4wMDAwIDEzMS4wMDAwIEwNCkINCipVDQp1DQoxLjUwMDAgdw0KICA0OTkuMDAwMCA5OS41 MDAwIG0NCiAgNDk5LjAwMDAgMTMwLjc1MDAgTA0KUw0KVQ0KdQ0KICA0NTkuNTAwMCA5OS41 MDAwIG0NCiAgNDU5LjUwMDAgMTMwLjc1MDAgTA0KUw0KVQ0KICAwLjAwMCAwLjAwMCAwLjAw MCAwLjAwMCBrDQowLjAwMDAgdw0KICAwLjAwMCAwLjAwMCAwLjAwMCAwLjAwMCBrDQogIDAu MDAwIDAuMDAwIDAuMDAwIDAuMDAwIGsNCip1DQogIDQ2Ny41MDAwIDEzMS4wMDAwIG0NCiAg NDY4Ljc1MDAgMTMxLjAwMDAgIDQ2OS43NTAwIDEzMi4wMDAwICA0NjkuNzUwMCAxMzMuMjUw MCBDDQogIDQ2OS43NTAwIDE0Mi43NTAwIEwNCiAgNDY5Ljc1MDAgMTQ0LjAwMDAgIDQ2OC43 NTAwIDE0NS4wMDAwICA0NjcuNTAwMCAxNDUuMDAwMCBDDQogIDQ1MC4yNTAwIDE0NS4wMDAw IEwNCiAgNDQ5LjAwMDAgMTQ1LjAwMDAgIDQ0OC4wMDAwIDE0My43NTAwICA0NDguMDAwMCAx NDIuNzUwMCBDDQogIDQ0OC4wMDAwIDEzMy4yNTAwIEwNCiAgNDQ4LjAwMDAgMTMyLjAwMDAg IDQ0OS4wMDAwIDEzMS4wMDAwICA0NTAuMjUwMCAxMzEuMDAwMCBDDQogIDQ2Ny41MDAwIDEz MS4wMDAwIEwNCkINCipVDQogIDAuMDAwIDAuMDAwIDAuMDAwIDAuMDAwIGsNCiAgMC4wMDAg MC4wMDAgMC4wMDAgMC4wMDAgaw0KICAwLjAwMCAwLjAwMCAwLjAwMCAwLjAwMCBrDQoqdQ0K ICA1MDcuMjUwMCAxMzEuMDAwMCBtDQogIDUwOC41MDAwIDEzMS4wMDAwICA1MDkuNTAwMCAx MzIuMDAwMCAgNTA5LjUwMDAgMTMzLjI1MDAgQw0KICA1MDkuNTAwMCAxNDIuNzUwMCBMDQog IDUwOS41MDAwIDE0NC4wMDAwICA1MDguNTAwMCAxNDUuMDAwMCAgNTA3LjI1MDAgMTQ1LjAw MDAgQw0KICA0OTAuMDAwMCAxNDUuMDAwMCBMDQogIDQ4OC43NTAwIDE0NS4wMDAwICA0ODcu NzUwMCAxNDMuNzUwMCAgNDg3Ljc1MDAgMTQyLjc1MDAgQw0KICA0ODcuNzUwMCAxMzMuMjUw MCBMDQogIDQ4Ny43NTAwIDEzMi4wMDAwICA0ODguNzUwMCAxMzEuMDAwMCAgNDkwLjAwMDAg MTMxLjAwMDAgQw0KICA1MDcuMjUwMCAxMzEuMDAwMCBMDQpCDQoqVQ0KdQ0KICAwLjAwMCAw LjAwMCAwLjAwMCAxLjAwMCBrDQogIDQwMC43NTAwIDk5LjUwMDAgbQ0KICA0MDEuMDAwMCAx MDIuMjUwMCBMDQogIDQwMS4wMDAwIDEwMi4yNTAwIEwNCiAgNDAxLjI1MDAgMTA0LjAwMDAg TA0KICA0MDEuMjUwMCAxMDQuMDAwMCBMDQogIDQwMS41MDAwIDEwNS43NTAwIEwNCiAgNDAy LjI1MDAgMTA3LjUwMDAgTA0KICA0MDIuMjUwMCAxMDcuNTAwMCBMDQogIDQwMy4wMDAwIDEw OS4wMDAwIEwNCiAgNDAzLjAwMDAgMTA5LjAwMDAgTA0KICA0MDQuMDAwMCAxMTAuNTAwMCBM DQogIDQwNS4wMDAwIDExMi4wMDAwIEwNCiAgNDA1LjAwMDAgMTEyLjAwMDAgTA0KICA0MDYu MDAwMCAxMTMuMjUwMCBMDQogIDQwNy41MDAwIDExNC41MDAwIEwNCiAgNDA3LjUwMDAgMTE0 LjI1MDAgTA0KICA0MDguNzUwMCAxMTUuNTAwMCBMDQogIDQwOC43NTAwIDExNS41MDAwIEwN CiAgNDEyLjAwMDAgMTE3LjI1MDAgTA0KICA0MTEuNzUwMCAxMTcuMDAwMCBMDQogIDQxMy41 MDAwIDExNy43NTAwIEwNCiAgNDE1LjI1MDAgMTE4LjI1MDAgTA0KICA0MTUuMjUwMCAxMTgu MjUwMCBMDQogIDQxNy4yNTAwIDExOC41MDAwIEwNCiAgNDE3LjAwMDAgMTE4LjUwMDAgTA0K ICA0MTkuMDAwMCAxMTguNTAwMCBMDQogIDQyMS4wMDAwIDExOC41MDAwIEwNCiAgNDIwLjc1 MDAgMTE4LjUwMDAgTA0KICA0MjIuNzUwMCAxMTguMjUwMCBMDQogIDQyMi41MDAwIDExOC4y NTAwIEwNCiAgNDI0LjUwMDAgMTE3Ljc1MDAgTA0KICA0MjYuMDAwMCAxMTcuMDAwMCBMDQog IDQyNi4wMDAwIDExNy4yNTAwIEwNCiAgNDI3Ljc1MDAgMTE2LjI1MDAgTA0KICA0MjcuNTAw MCAxMTYuMjUwMCBMDQogIDQyOS4yNTAwIDExNS41MDAwIEwNCiAgNDMwLjUwMDAgMTE0LjI1 MDAgTA0KICA0MzAuNTAwMCAxMTQuNTAwMCBMDQogIDQzMi4wMDAwIDExMy4yNTAwIEwNCiAg NDMzLjAwMDAgMTEyLjAwMDAgTA0KICA0MzMuMDAwMCAxMTIuMDAwMCBMDQogIDQzNC4wMDAw IDExMC41MDAwIEwNCiAgNDM1Ljc1MDAgMTA3LjUwMDAgTA0KICA0MzUuNzUwMCAxMDcuNTAw MCBMDQogIDQzNi41MDAwIDEwNS43NTAwIEwNCiAgNDM2Ljc1MDAgMTA0LjAwMDAgTA0KICA0 MzYuNzUwMCAxMDQuMDAwMCBMDQogIDQzNy4wMDAwIDEwMi4yNTAwIEwNCiAgNDM3LjAwMDAg MTAyLjI1MDAgTA0KICA0MzcuMjUwMCAxMDAuNTAwMCBMDQogIDQzNy4wMDAwIDk4LjUwMDAg TA0KICA0MzcuMDAwMCA5OC41MDAwIEwNCiAgNDM2Ljc1MDAgOTYuNzUwMCBMDQogIDQzNi43 NTAwIDk2Ljc1MDAgTA0KICA0MzYuNTAwMCA5NS4wMDAwIEwNCiAgNDM1Ljc1MDAgOTMuMjUw MCBMDQogIDQzNS43NTAwIDkzLjI1MDAgTA0KICA0MzQuMDAwMCA5MC4yNTAwIEwNCiAgNDMz LjAwMDAgODguNzUwMCBMDQogIDQzMy4wMDAwIDg5LjAwMDAgTA0KICA0MzIuMDAwMCA4Ny41 MDAwIEwNCiAgNDMwLjUwMDAgODYuMjUwMCBMDQogIDQzMC41MDAwIDg2LjUwMDAgTA0KICA0 MjkuMjUwMCA4NS4yNTAwIEwNCiAgNDI2LjAwMDAgODMuNzUwMCBMDQogIDQyNi4wMDAwIDgz Ljc1MDAgTA0KICA0MjQuNTAwMCA4My4wMDAwIEwNCiAgNDIyLjUwMDAgODIuNTAwMCBMDQog IDQyMi43NTAwIDgyLjUwMDAgTA0KICA0MjAuNzUwMCA4Mi4yNTAwIEwNCiAgNDIxLjAwMDAg ODIuMjUwMCBMDQogIDQxOS4wMDAwIDgyLjI1MDAgTA0KICA0MTcuMDAwMCA4Mi4yNTAwIEwN CiAgNDE3LjI1MDAgODIuMjUwMCBMDQogIDQxNS4yNTAwIDgyLjUwMDAgTA0KICA0MTUuMjUw MCA4Mi41MDAwIEwNCiAgNDEzLjUwMDAgODMuMDAwMCBMDQogIDQxMS43NTAwIDgzLjc1MDAg TA0KICA0MTIuMDAwMCA4My43NTAwIEwNCiAgNDA4Ljc1MDAgODUuMjUwMCBMDQogIDQwOC43 NTAwIDg1LjI1MDAgTA0KICA0MDcuNTAwMCA4Ni41MDAwIEwNCiAgNDA3LjUwMDAgODYuMjUw MCBMDQogIDQwNi4wMDAwIDg3LjUwMDAgTA0KICA0MDUuMDAwMCA4OS4wMDAwIEwNCiAgNDA1 LjAwMDAgODguNzUwMCBMDQogIDQwNC4wMDAwIDkwLjI1MDAgTA0KICA0MDMuMDAwMCA5MS43 NTAwIEwNCiAgNDAzLjAwMDAgOTEuNzUwMCBMDQogIDQwMi4yNTAwIDkzLjI1MDAgTA0KICA0 MDIuMjUwMCA5My4yNTAwIEwNCiAgNDAxLjUwMDAgOTUuMDAwMCBMDQogIDQwMS4yNTAwIDk2 Ljc1MDAgTA0KICA0MDEuMjUwMCA5Ni43NTAwIEwNCiAgNDAwLjc1MDAgMTAwLjUwMDAgTA0K ICA0MDAuNTAwMCAxMDAuNzUwMCBMDQogIDQwMC4wMDAwIDEwMC4yNTAwIEwNCiAgNDAwLjc1 MDAgOTkuNTAwMCBMDQogIDQwMC43NTAwIDEwMC43NTAwIEwNCiAgNDAwLjUwMDAgMTAwLjc1 MDAgTA0KICA0MDAuMDAwMCAxMDAuMjUwMCBMDQogIDQwMC4wMDAwIDEwMC4wMDAwIEwNCiAg NDAwLjAwMDAgMTAwLjUwMDAgTA0KICA0MDAuMjUwMCA5Ni41MDAwIEwNCiAgNDAwLjc1MDAg OTQuNzUwMCBMDQogIDQwMS41MDAwIDkzLjAwMDAgTA0KICA0MDIuMjUwMCA5MS4yNTAwIEwN CiAgNDAzLjAwMDAgODkuNzUwMCBMDQogIDQwNC4yNTAwIDg4LjI1MDAgTA0KICA0MDYuNzUw MCA4NS43NTAwIEwNCiAgNDA4LjI1MDAgODQuNTAwMCBMDQogIDQxMS41MDAwIDgyLjc1MDAg TA0KICA0MTMuMjUwMCA4Mi4yNTAwIEwNCiAgNDE1LjI1MDAgODEuNzUwMCBMDQogIDQxNy4w MDAwIDgxLjUwMDAgTA0KICA0MTkuMDAwMCA4MS4yNTAwIEwNCiAgNDIxLjAwMDAgODEuNTAw MCBMDQogIDQyMi43NTAwIDgxLjc1MDAgTA0KICA0MjQuNzUwMCA4Mi4yNTAwIEwNCiAgNDI2 LjUwMDAgODMuMDAwMCBMDQogIDQyOC4yNTAwIDgzLjc1MDAgTA0KICA0MjkuNzUwMCA4NC41 MDAwIEwNCiAgNDMxLjI1MDAgODUuNzUwMCBMDQogIDQzMi41MDAwIDg3LjAwMDAgTA0KICA0 MzMuNzUwMCA4OC4yNTAwIEwNCiAgNDM1LjAwMDAgODkuNzUwMCBMDQogIDQzNi43NTAwIDkz LjAwMDAgTA0KICA0MzcuMjUwMCA5NC43NTAwIEwNCiAgNDM3Ljc1MDAgOTYuNTAwMCBMDQog IDQzOC4wMDAwIDk4LjUwMDAgTA0KICA0MzguMjUwMCAxMDAuNTAwMCBMDQogIDQzOC4wMDAw IDEwMi4yNTAwIEwNCiAgNDM3Ljc1MDAgMTA0LjI1MDAgTA0KICA0MzcuMjUwMCAxMDYuMDAw MCBMDQogIDQzNi41MDAwIDEwNy43NTAwIEwNCiAgNDM1Ljc1MDAgMTA5LjUwMDAgTA0KICA0 MzUuMDAwMCAxMTEuMDAwMCBMDQogIDQzMy43NTAwIDExMi41MDAwIEwNCiAgNDMyLjUwMDAg MTEzLjc1MDAgTA0KICA0MzEuMDAwMCAxMTUuMjUwMCBMDQogIDQyOS43NTAwIDExNi4yNTAw IEwNCiAgNDI2LjUwMDAgMTE4LjAwMDAgTA0KICA0MjQuNzUwMCAxMTguNTAwMCBMDQogIDQy Mi43NTAwIDExOS4wMDAwIEwNCiAgNDIxLjAwMDAgMTE5LjI1MDAgTA0KICA0MTkuMDAwMCAx MTkuNTAwMCBMDQogIDQxNy4wMDAwIDExOS4yNTAwIEwNCiAgNDE1LjI1MDAgMTE5LjAwMDAg TA0KICA0MTMuMjUwMCAxMTguNTAwMCBMDQogIDQxMS41MDAwIDExOC4wMDAwIEwNCiAgNDA4 LjI1MDAgMTE2LjI1MDAgTA0KICA0MDYuNzUwMCAxMTUuMDAwMCBMDQogIDQwNS41MDAwIDEx My43NTAwIEwNCiAgNDA0LjI1MDAgMTEyLjUwMDAgTA0KICA0MDMuMDAwMCAxMTEuMDAwMCBM DQogIDQwMi4yNTAwIDEwOS41MDAwIEwNCiAgNDAxLjI1MDAgMTA3Ljc1MDAgTA0KICA0MDAu NzUwMCAxMDYuMDAwMCBMDQogIDQwMC4yNTAwIDEwNC4yNTAwIEwNCiAgNDAwLjAwMDAgMTAw LjUwMDAgTA0KICA0MDAuNzUwMCAxMDAuNzUwMCBMDQogIDQwMC43NTAwIDk5LjUwMDAgTA0K Rg0KVQ0KdQ0KICAwLjAwMCAwLjAwMCAwLjAwMCAxLjAwMCBrDQogIDQxNS4wMDAwIDkwLjI1 MDAgbQ0KICA0MTUuMDAwMCA5OC41MDAwIEwNCiAgNDE0LjUwMDAgOTguMDAwMCBMDQogIDQx NS4wMDAwIDk4LjAwMDAgTA0KICA0MTUuMDAwMCA5OS43NTAwIEwNCiAgNDE1LjAwMDAgOTku NzUwMCBMDQogIDQxNS41MDAwIDEwMS4wMDAwIEwNCiAgNDE1LjUwMDAgMTAxLjAwMDAgTA0K ICA0MTYuMDAwMCAxMDIuMDAwMCBMDQogIDQxNi4wMDAwIDEwMi4wMDAwIEwNCiAgNDE2Ljc1 MDAgMTAzLjAwMDAgTA0KICA0MTYuNzUwMCAxMDMuMDAwMCBMDQogIDQxNy43NTAwIDEwMy43 NTAwIEwNCiAgNDE3LjUwMDAgMTAzLjc1MDAgTA0KICA0MTguNzUwMCAxMDQuMjUwMCBMDQog IDQxOC43NTAwIDEwNC4yNTAwIEwNCiAgNDIwLjAwMDAgMTA0LjUwMDAgTA0KICA0MjAuMDAw MCAxMDQuNTAwMCBMDQogIDQyMS4yNTAwIDEwNC43NTAwIEwNCiAgNDIxLjI1MDAgMTA1Ljc1 MDAgTA0KICA0MjEuMDAwMCAxMDUuNzUwMCBMDQogIDQyMS4wMDAwIDEwNC43NTAwIEwNCiAg NDI5LjI1MDAgMTA0Ljc1MDAgTA0KICA0MjkuMjUwMCAxMDUuNzUwMCBMDQogIDQyMS4wMDAw IDEwNS43NTAwIEwNCiAgNDIxLjAwMDAgMTA0Ljc1MDAgTA0KICA0MjEuMjUwMCAxMDQuNzUw MCBMDQogIDQyMS4wMDAwIDEwNS43NTAwIEwNCiAgNDE5Ljc1MDAgMTA1LjUwMDAgTA0KICA0 MTguMjUwMCAxMDUuMDAwMCBMDQogIDQxNy4yNTAwIDEwNC41MDAwIEwNCiAgNDE2LjAwMDAg MTAzLjUwMDAgTA0KICA0MTUuMjUwMCAxMDIuNTAwMCBMDQogIDQxNC43NTAwIDEwMS4yNTAw IEwNCiAgNDE0LjI1MDAgMTAwLjAwMDAgTA0KICA0MTQuMDAwMCA5OC41MDAwIEwNCiAgNDE0 LjUwMDAgOTkuMDAwMCBMDQogIDQxNC4wMDAwIDk5LjAwMDAgTA0KICA0MTQuMDAwMCA5MC4y NTAwIEwNCiAgNDE1LjAwMDAgOTAuMjUwMCBMDQpGDQpVDQp1DQogIDAuMDAwIDAuMDAwIDAu MDAwIDEuMDAwIGsNCiAgNDIzLjUwMDAgMTEwLjUwMDAgbQ0KICA0MjMuNzUwMCAxMDEuNTAw MCBMDQogIDQyNC4wMDAwIDEwMS41MDAwIEwNCiAgNDIzLjc1MDAgMTAyLjAwMDAgTA0KICA0 MjMuNTAwMCAxMDAuNzUwMCBMDQogIDQyMy41MDAwIDEwMC43NTAwIEwNCiAgNDIzLjAwMDAg OTkuNTAwMCBMDQogIDQyMy4yNTAwIDk5LjUwMDAgTA0KICA0MjIuNTAwMCA5OC4yNTAwIEwN CiAgNDIyLjUwMDAgOTguMjUwMCBMDQogIDQyMS43NTAwIDk3LjI1MDAgTA0KICA0MjEuNzUw MCA5Ny41MDAwIEwNCiAgNDIwLjc1MDAgOTYuNTAwMCBMDQogIDQyMC43NTAwIDk2LjUwMDAg TA0KICA0MTkuNzUwMCA5Ni4wMDAwIEwNCiAgNDE5Ljc1MDAgOTYuMDAwMCBMDQogIDQxOC41 MDAwIDk1Ljc1MDAgTA0KICA0MTguNTAwMCA5NS43NTAwIEwNCiAgNDE3LjAwMDAgOTUuNTAw MCBMDQogIDQxNy4yNTAwIDk1LjUwMDAgTA0KICA0MDguNTAwMCA5NS41MDAwIEwNCiAgNDA4 LjUwMDAgOTQuNTAwMCBMDQogIDQxNy4yNTAwIDk0LjUwMDAgTA0KICA0MTguNzUwMCA5NC43 NTAwIEwNCiAgNDIwLjAwMDAgOTUuMjUwMCBMDQogIDQyMS4yNTAwIDk1Ljc1MDAgTA0KICA0 MjIuNTAwMCA5Ni43NTAwIEwNCiAgNDIzLjUwMDAgOTcuNzUwMCBMDQogIDQyNC4wMDAwIDk5 LjAwMDAgTA0KICA0MjQuNTAwMCAxMDAuNTAwMCBMDQogIDQyNC43NTAwIDEwMi41MDAwIEwN CiAgNDI0LjAwMDAgMTAyLjUwMDAgTA0KICA0MjQuNTAwMCAxMDIuMDAwMCBMDQogIDQyNC41 MDAwIDExMC41MDAwIEwNCiAgNDIzLjUwMDAgMTEwLjUwMDAgTA0KRg0KVQ0KdQ0KICAwLjAw MCAwLjAwMCAwLjAwMCAxLjAwMCBrDQogIDQyMS4wMDAwIDExMS4wMDAwIG0NCiAgNDIzLjUw MDAgMTE1LjUwMDAgTA0KICA0MjMuNTAwMCAxMTUuNTAwMCBMDQogIDQyNi4wMDAwIDExMS4w MDAwIEwNCiAgNDI2LjAwMDAgMTExLjAwMDAgTA0KICA0MjEuMDAwMCAxMTEuMDAwMCBMDQog IDQyMS4wMDAwIDExMS4wMDAwIEwNCiAgNDIxLjAwMDAgMTExLjAwMDAgTA0KQg0KVQ0KdQ0K ICAwLjAwMCAwLjAwMCAwLjAwMCAxLjAwMCBrDQogIDQyOS4yNTAwIDEwNy41MDAwIG0NCiAg NDMzLjUwMDAgMTA1LjAwMDAgTA0KICA0MzMuNTAwMCAxMDUuMDAwMCBMDQogIDQyOS4yNTAw IDEwMi43NTAwIEwNCiAgNDI5LjI1MDAgMTAyLjc1MDAgTA0KICA0MjkuMjUwMCAxMDcuNTAw MCBMDQogIDQyOS4yNTAwIDEwNy41MDAwIEwNCiAgNDI5LjI1MDAgMTA3LjUwMDAgTA0KQg0K VQ0KdQ0KICAwLjAwMCAwLjAwMCAwLjAwMCAxLjAwMCBrDQogIDQwOC43NTAwIDk3LjUwMDAg bQ0KICA0MDQuNTAwMCA5NS4yNTAwIEwNCiAgNDA0LjUwMDAgOTUuMjUwMCBMDQogIDQwOC43 NTAwIDkyLjc1MDAgTA0KICA0MDguNzUwMCA5Mi43NTAwIEwNCiAgNDA4Ljc1MDAgOTcuNTAw MCBMDQogIDQwOC43NTAwIDk3LjUwMDAgTA0KICA0MDguNzUwMCA5Ny41MDAwIEwNCkINClUN CnUNCiAgMC4wMDAgMC4wMDAgMC4wMDAgMS4wMDAgaw0KICA0MTEuNzUwMCA5MC4yNTAwIG0N CiAgNDE0LjI1MDAgODYuMDAwMCBMDQogIDQxNC4yNTAwIDg2LjAwMDAgTA0KICA0MTYuNTAw MCA5MC4yNTAwIEwNCiAgNDE2LjUwMDAgOTAuMjUwMCBMDQogIDQxMS43NTAwIDkwLjI1MDAg TA0KICA0MTEuNzUwMCA5MC4yNTAwIEwNCiAgNDExLjc1MDAgOTAuMjUwMCBMDQpCDQpVDQow IFRvDQoxIDAgMCAxIDQ2NiA0MS41IDAgVHANClRQDQovX0hlbHZldGljYSA0Ljc1MDAgVGYN CjAuMDAwMCBUYw0KIDAgVHINCiAgMC4wMDAgMC4wMDAgMC4wMDAgMS4wMDAgaw0KKE1vYmls ZSBIb3N0XHIpIFR4DQpUTw0KMCBUbw0KMSAwIDAgMSA0MDAgNzIgMCBUcA0KVFANCi9fSGVs dmV0aWNhIDYuMDAwMCBUZg0KMC4wMDAwIFRjDQogMCBUcg0KICAwLjAwMCAwLjAwMCAwLjAw MCAxLjAwMCBrDQooTW9iaWxlIFJvdXRlclxyKSBUeA0KVE8NCjAgVG8NCjEgMCAwIDEgMzUz IDExMy41IDAgVHANClRQDQovX0hlbHZldGljYSAxMC4wMDAwIFRmDQotMC4yNTAwIFRjDQog MCBUcg0KICAwLjAwMCAwLjAwMCAwLjAwMCAxLjAwMCBrDQooSVB2NFxyKSBUeA0KVE8NCjAg VG8NCjEgMCAwIDEgMjMzLjI1IDIxMSAwIFRwDQpUUA0KL19IZWx2ZXRpY2EgNi4wMDAwIFRm DQowLjAwMDAgVGMNCiAwIFRyDQogIDAuMDAwIDAuMDAwIDAuMDAwIDEuMDAwIGsNCihNb2Jp bGUgSG9zdCdzIEhvbWUgQWdlbnRccikgVHgNClRPDQogIDAuMDAwIDAuMDAwIDAuMDAwIDAu MDAwIGsNCiAgMC4wMDAgMC4wMDAgMC4wMDAgMC4wMDAgaw0KICAwLjAwMCAwLjAwMCAwLjAw MCAwLjAwMCBrDQoqdQ0KICA3Ny4wMDAwIDEzMi41MDAwIG0NCiAgNzguNTAwMCAxMzIuNTAw MCAgNzkuNTAwMCAxMzMuNzUwMCAgNzkuNTAwMCAxMzUuMDAwMCBDDQogIDc5LjUwMDAgMTQ1 LjI1MDAgTA0KICA3OS41MDAwIDE0Ni43NTAwICA3OC41MDAwIDE0Ny43NTAwICA3Ny4wMDAw IDE0Ny43NTAwIEMNCiAgNTYuNzUwMCAxNDcuNzUwMCBMDQogIDU1LjI1MDAgMTQ3Ljc1MDAg IDU0LjAwMDAgMTQ2Ljc1MDAgIDU0LjAwMDAgMTQ1LjI1MDAgQw0KICA1NC4yNTAwIDEzNS4w MDAwIEwNCiAgNTQuMDAwMCAxMzMuNzUwMCAgNTUuMjUwMCAxMzIuNTAwMCAgNTYuNzUwMCAx MzIuNTAwMCBDDQogIDc3LjAwMDAgMTMyLjUwMDAgTA0KQg0KKlUNCiAgMC4wMDAgMC4wMDAg MC4wMDAgMC4wMDAgaw0KICAyOTIuNzUwMCAyMjAuMDAwMCBtDQogIDI5Mi43NTAwIDIxNi41 MDAwICAyODkuMDAwMCAyMTQuMjUwMCAgMjg2LjAwMDAgMjE2LjAwMDAgQw0KICAyODMuMDAw MCAyMTcuNzUwMCAgMjgzLjAwMDAgMjIyLjAwMDAgIDI4Ni4wMDAwIDIyMy43NTAwIEMNCiAg Mjg5LjAwMDAgMjI1LjUwMDAgIDI5Mi43NTAwIDIyMy4yNTAwICAyOTIuNzUwMCAyMjAuMDAw MCBDDQpCDQp1DQogIDI5Mi41MDAwIDIyMS4yNTAwIG0NCiAgMzA2LjUwMDAgMTIyLjI1MDAg TA0KICAzMDguNzUwMCAxMTcuMDAwMCBMDQogIDMxMC41MDAwIDExMy43NTAwIEwNCiAgMzEy Ljc1MDAgMTEwLjUwMDAgTA0KICAzMTUuMDAwMCAxMDguMDAwMCBMDQogIDMxNy4wMDAwIDEw Ni43NTAwIEwNCiAgMzE5LjAwMDAgMTA1LjUwMDAgTA0KICAzMjEuMDAwMCAxMDUuMDAwMCBM DQogIDMyMi4yNTAwIDEwNS4wMDAwIEwNCiAgMzI0LjAwMDAgMTA1LjAwMDAgTA0KICAzMjUu NzUwMCAxMDUuMjUwMCBMDQpTDQpVDQp1DQogIDI4My43NTAwIDIyMC4wMDAwIG0NCiAgMjk3 Ljc1MDAgMTIxLjAwMDAgTA0KICAzMDAuNTAwMCAxMTUuMDAwMCBMDQogIDMwMi43NTAwIDEx MC41MDAwIEwNCiAgMzA1LjAwMDAgMTA3LjI1MDAgTA0KICAzMDcuMjUwMCAxMDQuMjUwMCBM DQogIDMwOS43NTAwIDEwMi4yNTAwIEwNCiAgMzExLjc1MDAgMTAwLjc1MDAgTA0KICAzMTMu NzUwMCA5OS43NTAwIEwNCiAgMzE1LjUwMDAgOTkuMDAwMCBMDQogIDMxNy4yNTAwIDk4Ljc1 MDAgTA0KICAzMTguNzUwMCA5OC43NTAwIEwNCiAgMzIwLjUwMDAgOTkuMDAwMCBMDQogIDMy Mi43NTAwIDk5LjUwMDAgTA0KUw0KVQ0KdQ0KICAwLjAwMCAwLjAwMCAwLjAwMCAxLjAwMCBr DQogIDI1MC41MDAwIDIzOC4yNTAwIG0NCiAgMjUwLjc1MDAgMjQxLjI1MDAgTA0KICAyNTAu NzUwMCAyNDEuMjUwMCBMDQogIDI1MS4wMDAwIDI0My4wMDAwIEwNCiAgMjUxLjAwMDAgMjQz LjAwMDAgTA0KICAyNTEuNTAwMCAyNDQuNzUwMCBMDQogIDI1Mi4wMDAwIDI0Ni41MDAwIEwN CiAgMjUyLjAwMDAgMjQ2LjI1MDAgTA0KICAyNTIuNzUwMCAyNDguMDAwMCBMDQogIDI1Mi43 NTAwIDI0OC4wMDAwIEwNCiAgMjU0Ljc1MDAgMjUwLjc1MDAgTA0KICAyNTQuNzUwMCAyNTAu NzUwMCBMDQogIDI1Ni4wMDAwIDI1Mi4yNTAwIEwNCiAgMjU3LjI1MDAgMjUzLjI1MDAgTA0K ICAyNTcuMjUwMCAyNTMuMjUwMCBMDQogIDI1OC41MDAwIDI1NC4yNTAwIEwNCiAgMjU4LjUw MDAgMjU0LjI1MDAgTA0KICAyNjEuNzUwMCAyNTYuMDAwMCBMDQogIDI2MS41MDAwIDI1Ni4w MDAwIEwNCiAgMjYzLjI1MDAgMjU2Ljc1MDAgTA0KICAyNjUuMjUwMCAyNTcuMDAwMCBMDQog IDI2NS4wMDAwIDI1Ny4wMDAwIEwNCiAgMjY3LjAwMDAgMjU3LjI1MDAgTA0KICAyNjcuMDAw MCAyNTcuMjUwMCBMDQogIDI2OC43NTAwIDI1Ny41MDAwIEwNCiAgMjcwLjc1MDAgMjU3LjI1 MDAgTA0KICAyNzAuNTAwMCAyNTcuMjUwMCBMDQogIDI3Mi41MDAwIDI1Ny4wMDAwIEwNCiAg MjcyLjUwMDAgMjU3LjAwMDAgTA0KICAyNzQuMjUwMCAyNTYuNzUwMCBMDQogIDI3Ni4wMDAw IDI1Ni4wMDAwIEwNCiAgMjc1Ljc1MDAgMjU2LjAwMDAgTA0KICAyNzkuMDAwMCAyNTQuMjUw MCBMDQogIDI4MC41MDAwIDI1My4yNTAwIEwNCiAgMjgwLjI1MDAgMjUzLjI1MDAgTA0KICAy ODEuNzUwMCAyNTIuMjUwMCBMDQogIDI4My4wMDAwIDI1MC43NTAwIEwNCiAgMjgyLjc1MDAg MjUwLjc1MDAgTA0KICAyODQuMDAwMCAyNDkuNTAwMCBMDQogIDI4NS43NTAwIDI0Ni4yNTAw IEwNCiAgMjg1LjUwMDAgMjQ2LjUwMDAgTA0KICAyODYuMjUwMCAyNDQuNzUwMCBMDQogIDI4 Ni43NTAwIDI0My4wMDAwIEwNCiAgMjg2Ljc1MDAgMjQzLjAwMDAgTA0KICAyODcuMDAwMCAy NDEuMjUwMCBMDQogIDI4Ny4wMDAwIDI0MS4yNTAwIEwNCiAgMjg3LjAwMDAgMjM5LjI1MDAg TA0KICAyODcuMDAwMCAyMzcuNTAwMCBMDQogIDI4Ny4wMDAwIDIzNy41MDAwIEwNCiAgMjg2 Ljc1MDAgMjM1Ljc1MDAgTA0KICAyODYuNzUwMCAyMzUuNzUwMCBMDQogIDI4Ni4yNTAwIDIz NC4wMDAwIEwNCiAgMjg1LjUwMDAgMjMyLjI1MDAgTA0KICAyODUuNzUwMCAyMzIuMjUwMCBM DQogIDI4NC4wMDAwIDIyOS4yNTAwIEwNCiAgMjgyLjc1MDAgMjI3Ljc1MDAgTA0KICAyODMu MDAwMCAyMjcuNzUwMCBMDQogIDI4MS43NTAwIDIyNi41MDAwIEwNCiAgMjgwLjI1MDAgMjI1 LjI1MDAgTA0KICAyODAuNTAwMCAyMjUuMjUwMCBMDQogIDI3OS4wMDAwIDIyNC4yNTAwIEwN CiAgMjc3LjUwMDAgMjIzLjI1MDAgTA0KICAyNzcuNTAwMCAyMjMuMjUwMCBMDQogIDI3NS43 NTAwIDIyMi41MDAwIEwNCiAgMjc2LjAwMDAgMjIyLjUwMDAgTA0KICAyNzQuMjUwMCAyMjIu MDAwMCBMDQogIDI3Mi41MDAwIDIyMS41MDAwIEwNCiAgMjcyLjUwMDAgMjIxLjUwMDAgTA0K ICAyNzAuNTAwMCAyMjEuMjUwMCBMDQogIDI3MC43NTAwIDIyMS4yNTAwIEwNCiAgMjY4Ljc1 MDAgMjIxLjAwMDAgTA0KICAyNjcuMDAwMCAyMjEuMjUwMCBMDQogIDI2Ny4wMDAwIDIyMS4y NTAwIEwNCiAgMjY1LjAwMDAgMjIxLjUwMDAgTA0KICAyNjUuMjUwMCAyMjEuNTAwMCBMDQog IDI2My4yNTAwIDIyMi4wMDAwIEwNCiAgMjYxLjUwMDAgMjIyLjUwMDAgTA0KICAyNjEuNzUw MCAyMjIuNTAwMCBMDQogIDI1OC41MDAwIDIyNC4yNTAwIEwNCiAgMjU4LjUwMDAgMjI0LjI1 MDAgTA0KICAyNTcuMjUwMCAyMjUuMjUwMCBMDQogIDI1Ny4yNTAwIDIyNS4yNTAwIEwNCiAg MjU2LjAwMDAgMjI2LjUwMDAgTA0KICAyNTQuNzUwMCAyMjcuNzUwMCBMDQogIDI1NC43NTAw IDIyNy43NTAwIEwNCiAgMjUyLjc1MDAgMjMwLjc1MDAgTA0KICAyNTIuNzUwMCAyMzAuNTAw MCBMDQogIDI1Mi4wMDAwIDIzMi4yNTAwIEwNCiAgMjUyLjAwMDAgMjMyLjI1MDAgTA0KICAy NTEuNTAwMCAyMzQuMDAwMCBMDQogIDI1MS4wMDAwIDIzNS43NTAwIEwNCiAgMjUxLjAwMDAg MjM1Ljc1MDAgTA0KICAyNTAuNTAwMCAyMzkuNTAwMCBMDQogIDI1MC41MDAwIDIzOS43NTAw IEwNCiAgMjQ5Ljc1MDAgMjM5LjAwMDAgTA0KICAyNTAuNTAwMCAyMzguMjUwMCBMDQogIDI1 MC41MDAwIDIzOS43NTAwIEwNCiAgMjQ5Ljc1MDAgMjM5LjAwMDAgTA0KICAyNDkuNzUwMCAy MzkuMDAwMCBMDQogIDI0OS43NTAwIDIzOS4yNTAwIEwNCiAgMjUwLjAwMDAgMjM1LjUwMDAg TA0KICAyNTAuNTAwMCAyMzMuNzUwMCBMDQogIDI1MS4yNTAwIDIzMi4wMDAwIEwNCiAgMjUy LjAwMDAgMjMwLjI1MDAgTA0KICAyNTMuMDAwMCAyMjguNzUwMCBMDQogIDI1NC4wMDAwIDIy Ny4yNTAwIEwNCiAgMjU1LjI1MDAgMjI1Ljc1MDAgTA0KICAyNTYuNzUwMCAyMjQuNTAwMCBM DQogIDI1OC4wMDAwIDIyMy41MDAwIEwNCiAgMjYxLjI1MDAgMjIxLjc1MDAgTA0KICAyNjMu MDAwMCAyMjEuMDAwMCBMDQogIDI2NS4wMDAwIDIyMC41MDAwIEwNCiAgMjY3LjAwMDAgMjIw LjUwMDAgTA0KICAyNjguNzUwMCAyMjAuMjUwMCBMDQogIDI3Mi43NTAwIDIyMC41MDAwIEwN CiAgMjc0LjUwMDAgMjIxLjAwMDAgTA0KICAyNzYuMjUwMCAyMjEuNzUwMCBMDQogIDI3OC4w MDAwIDIyMi41MDAwIEwNCiAgMjc5LjUwMDAgMjIzLjUwMDAgTA0KICAyODEuMDAwMCAyMjQu NTAwMCBMDQogIDI4Mi4yNTAwIDIyNS43NTAwIEwNCiAgMjgzLjUwMDAgMjI3LjI1MDAgTA0K ICAyODQuNzUwMCAyMjguNzUwMCBMDQogIDI4NS41MDAwIDIzMC4yNTAwIEwNCiAgMjg2LjUw MDAgMjMyLjAwMDAgTA0KICAyODcuMDAwMCAyMzMuNzUwMCBMDQogIDI4Ny41MDAwIDIzNS41 MDAwIEwNCiAgMjg3Ljc1MDAgMjM3LjUwMDAgTA0KICAyODguMDAwMCAyMzkuMjUwMCBMDQog IDI4Ny43NTAwIDI0MS4yNTAwIEwNCiAgMjg3LjUwMDAgMjQzLjI1MDAgTA0KICAyODcuMDAw MCAyNDUuMDAwMCBMDQogIDI4Ni4yNTAwIDI0Ni43NTAwIEwNCiAgMjg1LjUwMDAgMjQ4LjUw MDAgTA0KICAyODQuNzUwMCAyNTAuMDAwMCBMDQogIDI4My41MDAwIDI1MS41MDAwIEwNCiAg MjgyLjI1MDAgMjUyLjc1MDAgTA0KICAyODEuMDAwMCAyNTQuMDAwMCBMDQogIDI3OS41MDAw IDI1NS4wMDAwIEwNCiAgMjc2LjI1MDAgMjU3LjAwMDAgTA0KICAyNzQuNTAwMCAyNTcuNTAw MCBMDQogIDI3Mi41MDAwIDI1OC4wMDAwIEwNCiAgMjY4Ljc1MDAgMjU4LjI1MDAgTA0KICAy NjUuMDAwMCAyNTguMDAwMCBMDQogIDI2My4wMDAwIDI1Ny41MDAwIEwNCiAgMjYxLjI1MDAg MjU2Ljc1MDAgTA0KICAyNTguMDAwMCAyNTUuMDAwMCBMDQogIDI1Ni41MDAwIDI1NC4wMDAw IEwNCiAgMjU0LjAwMDAgMjUxLjUwMDAgTA0KICAyNTIuMDAwMCAyNDguNTAwMCBMDQogIDI1 MS4wMDAwIDI0Ni43NTAwIEwNCiAgMjUwLjUwMDAgMjQ1LjAwMDAgTA0KICAyNTAuMDAwMCAy NDMuMDAwMCBMDQogIDI0OS43NTAwIDI0MS4yNTAwIEwNCiAgMjQ5Ljc1MDAgMjM5LjI1MDAg TA0KICAyNTAuNTAwMCAyMzkuNTAwMCBMDQogIDI1MC41MDAwIDIzOC4yNTAwIEwNCkYNClUN CnUNCiAgMC4wMDAgMC4wMDAgMC4wMDAgMS4wMDAgaw0KICAyNjQuNzUwMCAyMjkuMjUwMCBt DQogIDI2NC43NTAwIDIzNy41MDAwIEwNCiAgMjY0LjI1MDAgMjM3LjAwMDAgTA0KICAyNjQu NzUwMCAyMzcuMDAwMCBMDQogIDI2NS4wMDAwIDIzOC43NTAwIEwNCiAgMjY1LjAwMDAgMjM4 Ljc1MDAgTA0KICAyNjUuMjUwMCAyNDAuMDAwMCBMDQogIDI2NS4yNTAwIDIzOS43NTAwIEwN CiAgMjY1Ljc1MDAgMjQxLjAwMDAgTA0KICAyNjUuNzUwMCAyNDEuMDAwMCBMDQogIDI2Ni41 MDAwIDI0MS43NTAwIEwNCiAgMjY2LjUwMDAgMjQxLjc1MDAgTA0KICAyNjcuNTAwMCAyNDIu NTAwMCBMDQogIDI2Ny41MDAwIDI0Mi41MDAwIEwNCiAgMjY4LjUwMDAgMjQzLjI1MDAgTA0K ICAyNjguNTAwMCAyNDMuMDAwMCBMDQogIDI2OS43NTAwIDI0My41MDAwIEwNCiAgMjY5Ljc1 MDAgMjQzLjUwMDAgTA0KICAyNzEuMDAwMCAyNDMuNTAwMCBMDQogIDI3MS4wMDAwIDI0NC41 MDAwIEwNCiAgMjcxLjAwMDAgMjQ0LjUwMDAgTA0KICAyNzEuMDAwMCAyNDMuNTAwMCBMDQog IDI3OS4wMDAwIDI0My41MDAwIEwNCiAgMjc5LjAwMDAgMjQ0LjUwMDAgTA0KICAyNzEuMDAw MCAyNDQuNTAwMCBMDQogIDI3MS4wMDAwIDI0My41MDAwIEwNCiAgMjcxLjAwMDAgMjQzLjUw MDAgTA0KICAyNzEuMDAwMCAyNDQuNTAwMCBMDQogIDI2OS41MDAwIDI0NC41MDAwIEwNCiAg MjY4LjI1MDAgMjQ0LjAwMDAgTA0KICAyNjcuMDAwMCAyNDMuMjUwMCBMDQogIDI2Ni4wMDAw IDI0Mi41MDAwIEwNCiAgMjY1LjAwMDAgMjQxLjUwMDAgTA0KICAyNjQuNTAwMCAyNDAuMjUw MCBMDQogIDI2NC4wMDAwIDIzOC43NTAwIEwNCiAgMjYzLjc1MDAgMjM3LjUwMDAgTA0KICAy NjQuMjUwMCAyMzguMDAwMCBMDQogIDI2My43NTAwIDIzNy43NTAwIEwNCiAgMjYzLjc1MDAg MjI5LjI1MDAgTA0KICAyNjQuNzUwMCAyMjkuMjUwMCBMDQpGDQpVDQp1DQogIDAuMDAwIDAu MDAwIDAuMDAwIDEuMDAwIGsNCiAgMjczLjUwMDAgMjQ5LjI1MDAgbQ0KICAyNzMuNTAwMCAy NDAuNTAwMCBMDQogIDI3NC4wMDAwIDI0MC4yNTAwIEwNCiAgMjczLjUwMDAgMjQxLjAwMDAg TA0KICAyNzMuMjUwMCAyMzkuNTAwMCBMDQogIDI3My4yNTAwIDIzOS41MDAwIEwNCiAgMjcy Ljc1MDAgMjM4LjI1MDAgTA0KICAyNzMuMDAwMCAyMzguMjUwMCBMDQogIDI3Mi4yNTAwIDIz Ny4yNTAwIEwNCiAgMjcyLjUwMDAgMjM3LjI1MDAgTA0KICAyNzEuNTAwMCAyMzYuMjUwMCBM DQogIDI3MS41MDAwIDIzNi4yNTAwIEwNCiAgMjcwLjUwMDAgMjM1LjUwMDAgTA0KICAyNzAu NzUwMCAyMzUuNTAwMCBMDQogIDI2OS41MDAwIDIzNS4wMDAwIEwNCiAgMjY5LjUwMDAgMjM1 LjAwMDAgTA0KICAyNjguMjUwMCAyMzQuNTAwMCBMDQogIDI2OC4yNTAwIDIzNC41MDAwIEwN CiAgMjY3LjAwMDAgMjM0LjUwMDAgTA0KICAyNjcuMDAwMCAyMzQuNTAwMCBMDQogIDI1OC4y NTAwIDIzNC41MDAwIEwNCiAgMjU4LjI1MDAgMjMzLjUwMDAgTA0KICAyNjcuMDAwMCAyMzMu NTAwMCBMDQogIDI2OC41MDAwIDIzMy41MDAwIEwNCiAgMjcwLjAwMDAgMjM0LjAwMDAgTA0K ICAyNzEuMjUwMCAyMzQuNzUwMCBMDQogIDI3Mi4yNTAwIDIzNS41MDAwIEwNCiAgMjczLjI1 MDAgMjM2Ljc1MDAgTA0KICAyNzMuNzUwMCAyMzguMDAwMCBMDQogIDI3NC4yNTAwIDIzOS4y NTAwIEwNCiAgMjc0LjUwMDAgMjQxLjI1MDAgTA0KICAyNzMuNzUwMCAyNDEuMjUwMCBMDQog IDI3NC4yNTAwIDI0MC43NTAwIEwNCiAgMjc0LjI1MDAgMjQ5LjI1MDAgTA0KICAyNzMuNTAw MCAyNDkuMjUwMCBMDQpGDQpVDQp1DQogIDAuMDAwIDAuMDAwIDAuMDAwIDEuMDAwIGsNCiAg MjcwLjc1MDAgMjUwLjAwMDAgbQ0KICAyNzMuMjUwMCAyNTQuMjUwMCBMDQogIDI3My4yNTAw IDI1NC4yNTAwIEwNCiAgMjc1Ljc1MDAgMjUwLjAwMDAgTA0KICAyNzUuNzUwMCAyNTAuMDAw MCBMDQogIDI3MC43NTAwIDI1MC4wMDAwIEwNCiAgMjcwLjc1MDAgMjUwLjAwMDAgTA0KICAy NzAuNzUwMCAyNTAuMDAwMCBMDQpCDQpVDQp1DQogIDAuMDAwIDAuMDAwIDAuMDAwIDEuMDAw IGsNCiAgMjc5LjAwMDAgMjQ2LjUwMDAgbQ0KICAyODMuNTAwMCAyNDQuMDAwMCBMDQogIDI4 My41MDAwIDI0NC4wMDAwIEwNCiAgMjc5LjAwMDAgMjQxLjUwMDAgTA0KICAyNzkuMDAwMCAy NDEuNTAwMCBMDQogIDI3OS4wMDAwIDI0Ni41MDAwIEwNCiAgMjc5LjAwMDAgMjQ2LjUwMDAg TA0KICAyNzkuMDAwMCAyNDYuNTAwMCBMDQpCDQpVDQp1DQogIDAuMDAwIDAuMDAwIDAuMDAw IDEuMDAwIGsNCiAgMjU4Ljc1MDAgMjM2LjUwMDAgbQ0KICAyNTQuNTAwMCAyMzQuMDAwMCBM DQogIDI1NC4yNTAwIDIzNC4wMDAwIEwNCiAgMjU4LjUwMDAgMjMxLjc1MDAgTA0KICAyNTgu NzUwMCAyMzEuNzUwMCBMDQogIDI1OC43NTAwIDIzNi41MDAwIEwNCiAgMjU4Ljc1MDAgMjM2 LjUwMDAgTA0KICAyNTguNzUwMCAyMzYuNTAwMCBMDQpCDQpVDQp1DQogIDAuMDAwIDAuMDAw IDAuMDAwIDEuMDAwIGsNCiAgMjYxLjUwMDAgMjI5LjI1MDAgbQ0KICAyNjQuMDAwMCAyMjUu MDAwMCBMDQogIDI2NC4wMDAwIDIyNS4wMDAwIEwNCiAgMjY2LjI1MDAgMjI5LjI1MDAgTA0K ICAyNjYuMjUwMCAyMjkuMjUwMCBMDQogIDI2MS41MDAwIDIyOS4yNTAwIEwNCiAgMjYxLjUw MDAgMjI5LjI1MDAgTA0KICAyNjEuNTAwMCAyMjkuMjUwMCBMDQpCDQpVDQowIFRvDQoxIDAg MCAxIDQ0NC43NSAyNS41IDAgVHANClRQDQovX0hlbHZldGljYSAxMC4wMDAwIFRmDQowLjAw MDAgVGMNCiAwIFRyDQogIDAuMDAwIDAuMDAwIDAuMDAwIDEuMDAwIGsNCihNb2JpbGUgTmV0 d29ya1xyKSBUeA0KVE8NCnUNCiAgNzkuNTAwMCAxNDIuMDAwMCBtDQogIDI3Mi43NTAwIDIz MC4yNTAwIEwNCiAgMjc1LjAwMDAgMjMxLjAwMDAgTA0KICAyNzcuNTAwMCAyMzEuMjUwMCBM DQogIDI3OS4yNTAwIDIzMS41MDAwIEwNCiAgMjgxLjI1MDAgMjMxLjAwMDAgTA0KICAyODMu MDAwMCAyMzAuNTAwMCBMDQogIDI4NC43NTAwIDIyOS4yNTAwIEwNCiAgMjg2LjI1MDAgMjI3 LjUwMDAgTA0KICAyODcuMjUwMCAyMjUuNTAwMCBMDQogIDI4OC4yNTAwIDIyMy4yNTAwIEwN CiAgMjg5LjAwMDAgMjIwLjAwMDAgTA0KICAyODkuMjUwMCAyMTguNzUwMCBMDQpTDQpVDQp1 DQogIDAuMDAwIDAuMDAwIDAuMDAwIDEuMDAwIGsNCiAgMjkzLjI1MDAgOTkuNTAwMCBtDQog IDI5My41MDAwIDEwMi4yNTAwIEwNCiAgMjkzLjUwMDAgMTAyLjI1MDAgTA0KICAyOTMuNzUw MCAxMDQuMDAwMCBMDQogIDI5My43NTAwIDEwNC4wMDAwIEwNCiAgMjk0LjAwMDAgMTA1Ljc1 MDAgTA0KICAyOTQuNzUwMCAxMDcuNTAwMCBMDQogIDI5NC43NTAwIDEwNy4yNTAwIEwNCiAg Mjk1LjUwMDAgMTA5LjAwMDAgTA0KICAyOTUuNTAwMCAxMDkuMDAwMCBMDQogIDI5Ny41MDAw IDExMi4wMDAwIEwNCiAgMjk3LjUwMDAgMTExLjc1MDAgTA0KICAyOTguNzUwMCAxMTMuMjUw MCBMDQogIDMwMC4wMDAwIDExNC4yNTAwIEwNCiAgMjk5Ljc1MDAgMTE0LjI1MDAgTA0KICAz MDEuMjUwMCAxMTUuNTAwMCBMDQogIDMwMS4yNTAwIDExNS41MDAwIEwNCiAgMzA0LjUwMDAg MTE3LjAwMDAgTA0KICAzMDQuMjUwMCAxMTcuMDAwMCBMDQogIDMwNi4wMDAwIDExNy43NTAw IEwNCiAgMzA4LjAwMDAgMTE4LjAwMDAgTA0KICAzMDcuNzUwMCAxMTguMDAwMCBMDQogIDMw OS43NTAwIDExOC4yNTAwIEwNCiAgMzA5LjUwMDAgMTE4LjI1MDAgTA0KICAzMTEuNTAwMCAx MTguNTAwMCBMDQogIDMxMy41MDAwIDExOC4yNTAwIEwNCiAgMzEzLjI1MDAgMTE4LjI1MDAg TA0KICAzMTUuMjUwMCAxMTguMDAwMCBMDQogIDMxNS4yNTAwIDExOC4wMDAwIEwNCiAgMzE3 LjAwMDAgMTE3Ljc1MDAgTA0KICAzMTguNTAwMCAxMTcuMDAwMCBMDQogIDMxOC41MDAwIDEx Ny4wMDAwIEwNCiAgMzIxLjc1MDAgMTE1LjUwMDAgTA0KICAzMjMuMDAwMCAxMTQuMjUwMCBM DQogIDMyMy4wMDAwIDExNC4yNTAwIEwNCiAgMzI0LjUwMDAgMTEzLjI1MDAgTA0KICAzMjUu NTAwMCAxMTEuNzUwMCBMDQogIDMyNS41MDAwIDExMi4wMDAwIEwNCiAgMzI2LjUwMDAgMTEw LjUwMDAgTA0KICAzMjguMjUwMCAxMDcuMjUwMCBMDQogIDMyOC4yNTAwIDEwNy41MDAwIEwN CiAgMzI5LjAwMDAgMTA1Ljc1MDAgTA0KICAzMjkuMjUwMCAxMDQuMDAwMCBMDQogIDMyOS4y NTAwIDEwNC4wMDAwIEwNCiAgMzI5LjUwMDAgMTAyLjI1MDAgTA0KICAzMjkuNTAwMCAxMDIu MjUwMCBMDQogIDMyOS43NTAwIDEwMC4yNTAwIEwNCiAgMzI5LjUwMDAgOTguNTAwMCBMDQog IDMyOS41MDAwIDk4LjUwMDAgTA0KICAzMjkuMjUwMCA5Ni43NTAwIEwNCiAgMzI5LjI1MDAg OTYuNzUwMCBMDQogIDMyOS4wMDAwIDk1LjAwMDAgTA0KICAzMjguMjUwMCA5My4yNTAwIEwN CiAgMzI4LjI1MDAgOTMuMjUwMCBMDQogIDMyNi41MDAwIDkwLjI1MDAgTA0KICAzMjUuNTAw MCA4OC43NTAwIEwNCiAgMzI1LjUwMDAgODguNzUwMCBMDQogIDMyNC41MDAwIDg3LjUwMDAg TA0KICAzMjMuMDAwMCA4Ni4yNTAwIEwNCiAgMzIzLjAwMDAgODYuMjUwMCBMDQogIDMyMS43 NTAwIDg1LjI1MDAgTA0KICAzMjAuMjUwMCA4NC41MDAwIEwNCiAgMzIwLjI1MDAgODQuNTAw MCBMDQogIDMxOC41MDAwIDgzLjUwMDAgTA0KICAzMTguNTAwMCA4My43NTAwIEwNCiAgMzE3 LjAwMDAgODMuMDAwMCBMDQogIDMxNS4yNTAwIDgyLjUwMDAgTA0KICAzMTUuMjUwMCA4Mi41 MDAwIEwNCiAgMzEzLjI1MDAgODIuMjUwMCBMDQogIDMxMy41MDAwIDgyLjI1MDAgTA0KICAz MTEuNTAwMCA4Mi4yNTAwIEwNCiAgMzA5LjUwMDAgODIuMjUwMCBMDQogIDMwOS43NTAwIDgy LjI1MDAgTA0KICAzMDcuNzUwMCA4Mi41MDAwIEwNCiAgMzA4LjAwMDAgODIuNTAwMCBMDQog IDMwNi4wMDAwIDgzLjAwMDAgTA0KICAzMDQuMjUwMCA4My43NTAwIEwNCiAgMzA0LjUwMDAg ODMuNTAwMCBMDQogIDMwMS4yNTAwIDg1LjI1MDAgTA0KICAzMDEuMjUwMCA4NS4yNTAwIEwN CiAgMjk5Ljc1MDAgODYuMjUwMCBMDQogIDMwMC4wMDAwIDg2LjI1MDAgTA0KICAyOTguNzUw MCA4Ny41MDAwIEwNCiAgMjk3LjUwMDAgODguNzUwMCBMDQogIDI5Ny41MDAwIDg4Ljc1MDAg TA0KICAyOTUuNTAwMCA5MS43NTAwIEwNCiAgMjk1LjUwMDAgOTEuNzUwMCBMDQogIDI5NC43 NTAwIDkzLjI1MDAgTA0KICAyOTQuNzUwMCA5My4yNTAwIEwNCiAgMjk0LjAwMDAgOTUuMDAw MCBMDQogIDI5My43NTAwIDk2Ljc1MDAgTA0KICAyOTMuNzUwMCA5Ni43NTAwIEwNCiAgMjkz LjI1MDAgMTAwLjUwMDAgTA0KICAyOTMuMDAwMCAxMDAuNzUwMCBMDQogIDI5Mi41MDAwIDEw MC4wMDAwIEwNCiAgMjkzLjI1MDAgOTkuNTAwMCBMDQogIDI5My4yNTAwIDEwMC43NTAwIEwN CiAgMjkzLjAwMDAgMTAwLjc1MDAgTA0KICAyOTIuNTAwMCAxMDAuMDAwMCBMDQogIDI5Mi41 MDAwIDEwMC4wMDAwIEwNCiAgMjkyLjUwMDAgMTAwLjI1MDAgTA0KICAyOTIuNzUwMCA5Ni41 MDAwIEwNCiAgMjkzLjI1MDAgOTQuNzUwMCBMDQogIDI5NC4wMDAwIDkzLjAwMDAgTA0KICAy OTQuNzUwMCA5MS4yNTAwIEwNCiAgMjk1Ljc1MDAgODkuNzUwMCBMDQogIDI5Ni43NTAwIDg4 LjI1MDAgTA0KICAyOTguMDAwMCA4Ni43NTAwIEwNCiAgMjk5LjI1MDAgODUuNTAwMCBMDQog IDMwMC43NTAwIDg0LjUwMDAgTA0KICAzMDQuMDAwMCA4Mi43NTAwIEwNCiAgMzA1Ljc1MDAg ODIuMjUwMCBMDQogIDMwNy43NTAwIDgxLjc1MDAgTA0KICAzMTEuNTAwMCA4MS4yNTAwIEwN CiAgMzE1LjI1MDAgODEuNzUwMCBMDQogIDMxNy4yNTAwIDgyLjI1MDAgTA0KICAzMTkuMDAw MCA4Mi43NTAwIEwNCiAgMzIyLjI1MDAgODQuNTAwMCBMDQogIDMyMy43NTAwIDg1Ljc1MDAg TA0KICAzMjUuMDAwMCA4Ni43NTAwIEwNCiAgMzI2LjI1MDAgODguMjUwMCBMDQogIDMyNy4y NTAwIDg5Ljc1MDAgTA0KICAzMjguMjUwMCA5MS4yNTAwIEwNCiAgMzI5LjI1MDAgOTMuMDAw MCBMDQogIDMyOS43NTAwIDk0Ljc1MDAgTA0KICAzMzAuMjUwMCA5Ni41MDAwIEwNCiAgMzMw LjUwMDAgOTguNTAwMCBMDQogIDMzMC41MDAwIDEwMC4yNTAwIEwNCiAgMzMwLjUwMDAgMTAy LjI1MDAgTA0KICAzMzAuMjUwMCAxMDQuMjUwMCBMDQogIDMyOS43NTAwIDEwNi4wMDAwIEwN CiAgMzI5LjAwMDAgMTA3Ljc1MDAgTA0KICAzMjguMjUwMCAxMDkuNTAwMCBMDQogIDMyNy4y NTAwIDExMS4wMDAwIEwNCiAgMzI2LjI1MDAgMTEyLjUwMDAgTA0KICAzMjUuMDAwMCAxMTMu NzUwMCBMDQogIDMyMy41MDAwIDExNS4wMDAwIEwNCiAgMzIyLjI1MDAgMTE2LjI1MDAgTA0K ICAzMTguNzUwMCAxMTguMDAwMCBMDQogIDMxNy4yNTAwIDExOC41MDAwIEwNCiAgMzE1LjI1 MDAgMTE5LjAwMDAgTA0KICAzMTMuNTAwMCAxMTkuMjUwMCBMDQogIDMxMS41MDAwIDExOS4y NTAwIEwNCiAgMzA5LjUwMDAgMTE5LjI1MDAgTA0KICAzMDcuNTAwMCAxMTkuMDAwMCBMDQog IDMwNS43NTAwIDExOC41MDAwIEwNCiAgMzA0LjAwMDAgMTE3Ljc1MDAgTA0KICAzMDAuNzUw MCAxMTYuMjUwMCBMDQogIDI5OS4yNTAwIDExNS4wMDAwIEwNCiAgMjk2Ljc1MDAgMTEyLjUw MDAgTA0KICAyOTUuNzUwMCAxMTEuMDAwMCBMDQogIDI5NC43NTAwIDEwOS41MDAwIEwNCiAg MjkzLjc1MDAgMTA3Ljc1MDAgTA0KICAyOTMuMjUwMCAxMDYuMDAwMCBMDQogIDI5Mi43NTAw IDEwNC4yNTAwIEwNCiAgMjkyLjUwMDAgMTAwLjI1MDAgTA0KICAyOTMuMjUwMCAxMDAuNzUw MCBMDQogIDI5My4yNTAwIDk5LjUwMDAgTA0KRg0KVQ0KdQ0KICAwLjAwMCAwLjAwMCAwLjAw MCAxLjAwMCBrDQogIDMwNy41MDAwIDkwLjI1MDAgbQ0KICAzMDcuNTAwMCA5OC41MDAwIEwN CiAgMzA3LjAwMDAgOTguMDAwMCBMDQogIDMwNy41MDAwIDk4LjAwMDAgTA0KICAzMDcuNTAw MCA5OS43NTAwIEwNCiAgMzA3LjUwMDAgOTkuNzUwMCBMDQogIDMwOC4wMDAwIDEwMS4wMDAw IEwNCiAgMzA4LjAwMDAgMTAwLjc1MDAgTA0KICAzMDguNTAwMCAxMDIuMDAwMCBMDQogIDMw OC41MDAwIDEwMi4wMDAwIEwNCiAgMzA5LjI1MDAgMTAzLjAwMDAgTA0KICAzMDkuMjUwMCAx MDIuNzUwMCBMDQogIDMxMC4yNTAwIDEwMy43NTAwIEwNCiAgMzEwLjI1MDAgMTAzLjUwMDAg TA0KICAzMTEuMjUwMCAxMDQuMjUwMCBMDQogIDMxMS4yNTAwIDEwNC4yNTAwIEwNCiAgMzEy LjUwMDAgMTA0LjUwMDAgTA0KICAzMTIuNTAwMCAxMDQuNTAwMCBMDQogIDMxMy43NTAwIDEw NC43NTAwIEwNCiAgMzEzLjc1MDAgMTA1LjUwMDAgTA0KICAzMTMuNTAwMCAxMDUuNTAwMCBM DQogIDMxMy41MDAwIDEwNC43NTAwIEwNCiAgMzIxLjc1MDAgMTA0Ljc1MDAgTA0KICAzMjEu NzUwMCAxMDUuNTAwMCBMDQogIDMxMy41MDAwIDEwNS41MDAwIEwNCiAgMzEzLjUwMDAgMTA0 Ljc1MDAgTA0KICAzMTMuNzUwMCAxMDQuNzUwMCBMDQogIDMxMy41MDAwIDEwNS41MDAwIEwN CiAgMzEyLjI1MDAgMTA1LjUwMDAgTA0KICAzMTAuNzUwMCAxMDUuMDAwMCBMDQogIDMwOS43 NTAwIDEwNC4yNTAwIEwNCiAgMzA4LjUwMDAgMTAzLjUwMDAgTA0KICAzMDcuNzUwMCAxMDIu NTAwMCBMDQogIDMwNy4yNTAwIDEwMS4yNTAwIEwNCiAgMzA2Ljc1MDAgOTkuNzUwMCBMDQog IDMwNi41MDAwIDk4LjUwMDAgTA0KICAzMDcuMDAwMCA5OS4wMDAwIEwNCiAgMzA2LjUwMDAg OTkuMDAwMCBMDQogIDMwNi41MDAwIDkwLjI1MDAgTA0KICAzMDcuNTAwMCA5MC4yNTAwIEwN CkYNClUNCnUNCiAgMC4wMDAgMC4wMDAgMC4wMDAgMS4wMDAgaw0KICAzMTYuMDAwMCAxMTAu MjUwMCBtDQogIDMxNi4yNTAwIDEwMS41MDAwIEwNCiAgMzE2Ljc1MDAgMTAxLjUwMDAgTA0K ICAzMTYuMjUwMCAxMDIuMDAwMCBMDQogIDMxNi4wMDAwIDEwMC41MDAwIEwNCiAgMzE2LjAw MDAgMTAwLjc1MDAgTA0KICAzMTUuNTAwMCA5OS4yNTAwIEwNCiAgMzE1Ljc1MDAgOTkuNTAw MCBMDQogIDMxNS4wMDAwIDk4LjI1MDAgTA0KICAzMTUuMDAwMCA5OC4yNTAwIEwNCiAgMzE0 LjI1MDAgOTcuMjUwMCBMDQogIDMxNC4yNTAwIDk3LjI1MDAgTA0KICAzMTMuMjUwMCA5Ni41 MDAwIEwNCiAgMzEzLjUwMDAgOTYuNTAwMCBMDQogIDMxMi4yNTAwIDk2LjAwMDAgTA0KICAz MTIuMjUwMCA5Ni4wMDAwIEwNCiAgMzExLjAwMDAgOTUuNTAwMCBMDQogIDMxMS4wMDAwIDk1 LjUwMDAgTA0KICAzMDkuNTAwMCA5NS41MDAwIEwNCiAgMzA5Ljc1MDAgOTUuNTAwMCBMDQog IDMwMS4wMDAwIDk1LjUwMDAgTA0KICAzMDEuMDAwMCA5NC41MDAwIEwNCiAgMzA5Ljc1MDAg OTQuNTAwMCBMDQogIDMxMS4yNTAwIDk0Ljc1MDAgTA0KICAzMTIuNTAwMCA5NS4wMDAwIEwN CiAgMzEzLjc1MDAgOTUuNzUwMCBMDQogIDMxNS4wMDAwIDk2LjUwMDAgTA0KICAzMTUuNzUw MCA5Ny43NTAwIEwNCiAgMzE2LjUwMDAgOTkuMDAwMCBMDQogIDMxNy4wMDAwIDEwMC41MDAw IEwNCiAgMzE3LjAwMDAgMTAyLjI1MDAgTA0KICAzMTYuNTAwMCAxMDIuMjUwMCBMDQogIDMx Ny4wMDAwIDEwMi4wMDAwIEwNCiAgMzE3LjAwMDAgMTEwLjI1MDAgTA0KICAzMTYuMDAwMCAx MTAuMjUwMCBMDQpGDQpVDQp1DQogIDAuMDAwIDAuMDAwIDAuMDAwIDEuMDAwIGsNCiAgMzEz LjUwMDAgMTExLjAwMDAgbQ0KICAzMTYuMDAwMCAxMTUuMjUwMCBMDQogIDMxNi4wMDAwIDEx NS4yNTAwIEwNCiAgMzE4LjUwMDAgMTExLjAwMDAgTA0KICAzMTguNTAwMCAxMTEuMDAwMCBM DQogIDMxMy41MDAwIDExMS4wMDAwIEwNCiAgMzEzLjUwMDAgMTExLjAwMDAgTA0KICAzMTMu NTAwMCAxMTEuMDAwMCBMDQpCDQpVDQp1DQogIDAuMDAwIDAuMDAwIDAuMDAwIDEuMDAwIGsN CiAgMzIxLjc1MDAgMTA3LjUwMDAgbQ0KICAzMjYuMDAwMCAxMDUuMDAwMCBMDQogIDMyNi4w MDAwIDEwNS4wMDAwIEwNCiAgMzIxLjc1MDAgMTAyLjUwMDAgTA0KICAzMjEuNzUwMCAxMDIu NTAwMCBMDQogIDMyMS43NTAwIDEwNy41MDAwIEwNCiAgMzIxLjc1MDAgMTA3LjUwMDAgTA0K ICAzMjEuNzUwMCAxMDcuNTAwMCBMDQpCDQpVDQp1DQogIDAuMDAwIDAuMDAwIDAuMDAwIDEu MDAwIGsNCiAgMzAxLjUwMDAgOTcuNTAwMCBtDQogIDI5Ny4wMDAwIDk1LjAwMDAgTA0KICAy OTcuMDAwMCA5NS4wMDAwIEwNCiAgMzAxLjI1MDAgOTIuNzUwMCBMDQogIDMwMS41MDAwIDky Ljc1MDAgTA0KICAzMDEuNTAwMCA5Ny41MDAwIEwNCiAgMzAxLjUwMDAgOTcuNTAwMCBMDQog IDMwMS41MDAwIDk3LjUwMDAgTA0KQg0KVQ0KdQ0KICAwLjAwMCAwLjAwMCAwLjAwMCAxLjAw MCBrDQogIDMwNC4yNTAwIDkwLjI1MDAgbQ0KICAzMDYuNzUwMCA4Ni4wMDAwIEwNCiAgMzA2 Ljc1MDAgODYuMDAwMCBMDQogIDMwOS4wMDAwIDkwLjI1MDAgTA0KICAzMDkuMDAwMCA5MC4y NTAwIEwNCiAgMzA0LjI1MDAgOTAuMjUwMCBMDQogIDMwNC4yNTAwIDkwLjI1MDAgTA0KICAz MDQuMjUwMCA5MC4yNTAwIEwNCkINClUNCjAgVG8NCjEgMCAwIDEgMjk0LjUgNzIgMCBUcA0K VFANCi9fSGVsdmV0aWNhIDYuMDAwMCBUZg0KMC4wMDAwIFRjDQogMCBUcg0KICAwLjAwMCAw LjAwMCAwLjAwMCAxLjAwMCBrDQooRWRnZSBSb3V0ZXJccikgVHgNClRPDQowIFRvDQoxIDAg MCAxIDQ1IDEyNi41IDAgVHANClRQDQovX0hlbHZldGljYSA0Ljc1MDAgVGYNCjAuMDAwMCBU Yw0KIDAgVHINCiAgMC4wMDAgMC4wMDAgMC4wMDAgMS4wMDAgaw0KKENvcnJlc3BvbmRlbnQg Tm9kZVxyKSBUeA0KVE8NCiAgMC4wMDAgMC4yMDAgMC4yMDAgMC44MDAgSw0KICAzMjIuNzUw MCAxMDUuMjUwMCBtDQogIDMyNC4wMDAwIDEwNS4yNTAwICAzMjQuNzUwMCAxMDQuNzUwMCAg MzI1LjI1MDAgMTAzLjc1MDAgQw0KICAzMjUuNzUwMCAxMDMuMDAwMCAgMzI1Ljc1MDAgMTAy LjAwMDAgIDMyNS4yNTAwIDEwMS4wMDAwIEMNCiAgMzI0Ljc1MDAgMTAwLjI1MDAgIDMyNC4w MDAwIDk5LjUwMDAgIDMyMi43NTAwIDk5LjUwMDAgQw0KUw0KICAwLjAwMCAwLjAwMCAwLjAw MCAwLjg3MSBLDQogIDMyMC4wMDAwIDEwNS4yNTAwIG0NCiAgMzIxLjAwMDAgMTA2LjUwMDAg IDMyMS4yNTAwIDEwOC4wMDAwICAzMjIuNzUwMCAxMDguMDAwMCBDDQogIDMyNS41MDAwIDEw OC4wMDAwICAzMjguNTAwMCAxMDUuMDAwMCAgMzI4LjUwMDAgMTAyLjUwMDAgQw0KICAzMjgu NTAwMCA5OS43NTAwICAzMjUuNTAwMCA5Ni43NTAwICAzMjIuNzUwMCA5Ni43NTAwIEMNCiAg MzIxLjI1MDAgOTYuNzUwMCAgMzIxLjAwMDAgOTguNTAwMCAgMzIwLjAwMDAgOTkuNTAwMCBD DQpTDQp1DQogIDAuMDAwIDAuMDAwIDAuMDAwIDAuNDk4IGsNCiAgMC4wMDAgMC4wMDAgMC4w MDAgMC4yNDcgSw0KICAzMjIuNzUwMCAxMDguMDAwMCBtDQogIDMyMi43NTAwIDEwOC4wMDAw IEwNCiAgMzIyLjc1MDAgMTA4LjAwMDAgTA0KQg0KVQ0KdQ0KICAwLjAwMCAwLjAwMCAwLjAw MCAwLjg3MSBLDQogIDMyMi43NTAwIDEwOC4wMDAwIG0NCiAgNDA1LjAwMDAgMTA4LjAwMDAg TA0KICA0MDYuNzUwMCAxMDYuMjUwMCBMDQogIDQwNy41MDAwIDEwNC43NTAwIEwNCiAgNDA3 Ljc1MDAgMTAzLjAwMDAgTA0KICA0MDcuNzUwMCAxMDEuNzUwMCBMDQogIDQwNy4yNTAwIDEw MC4wMDAwIEwNCiAgNDA2LjI1MDAgOTguMjUwMCBMDQogIDQwNS4wMDAwIDk2Ljc1MDAgTA0K ICAzMjIuNzUwMCA5Ni43NTAwIEwNClMNClUNCnUNCiAgNDA4LjAwMDAgMTA1LjI1MDAgbQ0K ICA0MTMuNTAwMCAxMDUuMjUwMCBMDQogIDQxNS41MDAwIDEwNC4yNTAwIEwNCiAgNDE2LjI1 MDAgMTAzLjAwMDAgTA0KICA0MTYuNTAwMCAxMDIuNzUwMCBMDQogIDQxNi4yNTAwIDEwMi4w MDAwIEwNCiAgNDE1Ljc1MDAgMTAxLjI1MDAgTA0KICA0MTQuNTAwMCAxMDAuMjUwMCBMDQog IDQxMy41MDAwIDk5LjUwMDAgTA0KICA0MDguMDAwMCA5OS41MDAwIEwNClMNClUNCnUNCiAg NDE2LjUwMDAgMTAyLjUwMDAgbQ0KICA0NzkuMDAwMCAxMDIuNTAwMCBMDQogIDQ4MC4wMDAw IDEwMi41MDAwIEwNCiAgNDgxLjAwMDAgMTAyLjUwMDAgTA0KICA0ODIuMjUwMCAxMDIuMDAw MCBMDQogIDQ4My4yNTAwIDEwMS4wMDAwIEwNCiAgNDg0LjUwMDAgOTkuNTAwMCBMDQogIDQ4 NS41MDAwIDk3LjI1MDAgTA0KICA0ODYuMjUwMCA5NC41MDAwIEwNCiAgNDg3LjAwMDAgOTAu NzUwMCBMDQogIDQ4Ny4yNTAwIDg4LjI1MDAgTA0KICA0ODcuMjUwMCA1MS41MDAwIEwNClMN ClUNCiAgMC4wMDAgMC4wMDAgMC4wMDAgMC4wMDAgaw0KICAzMTcuMjUwMCA5MS4wMDAwIG0N CiAgMzE3LjI1MDAgODkuMDAwMCAgMzE0Ljc1MDAgODcuNTAwMCAgMzEzLjAwMDAgODguNzUw MCBDDQogIDMxMS4wMDAwIDg5Ljc1MDAgIDMxMS4wMDAwIDkyLjUwMDAgIDMxMy4wMDAwIDkz LjUwMDAgQw0KICAzMTQuNzUwMCA5NC43NTAwICAzMTcuMjUwMCA5My4yNTAwICAzMTcuMjUw MCA5MS4wMDAwIEMNCkINCiAgMC4wMDAgMC4wMDAgMC4wMDAgMS4wMDAgSw0KICAzMTQuNzUw MCA5MS4wMDAwIG0NCiAgMzA5LjI1MDAgOTIuMDAwMCAgMzAzLjUwMDAgOTMuMDAwMCAgMjk3 Ljc1MDAgOTQuMDAwMCBDDQogIDI5Mi4yNTAwIDk1LjAwMDAgIDI4Ni41MDAwIDk1Ljc1MDAg IDI4MC43NTAwIDk2Ljc1MDAgQw0KICAyODAuNzUwMCA5Ni43NTAwICA3OS41MDAwIDEzOS4y NTAwICA3OS41MDAwIDEzOS4yNTAwIEMNClMNCnUNCiAgMC4wMDAgMC4wMDAgMC4wMDAgMS4w MDAgaw0KICA4My41MDAwIDEzNi4yNTAwIG0NCiAgNzkuNTAwMCAxMzkuMjUwMCBMDQogIDg0 LjUwMDAgMTQwLjUwMDAgTA0KICA4My41MDAwIDEzNi4yNTAwIEwNCkINClUNCnUNCiAgMC4w MDAgMC4wMDAgMC4wMDAgMC44NzEgSw0KICAzMTQuMjUwMCA4OC4yNTAwIG0NCiAgNDA4LjAw MDAgODguMjUwMCBMDQogIDQwOS43NTAwIDg5LjUwMDAgTA0KICA0MTAuNTAwMCA5MC41MDAw IEwNCiAgNDEwLjc1MDAgOTEuMDAwMCBMDQogIDQxMC43NTAwIDkxLjUwMDAgTA0KICA0MTAu MjUwMCA5Mi41MDAwIEwNCiAgNDA4Ljc1MDAgOTMuNTAwMCBMDQogIDQwOC4wMDAwIDk0LjAw MDAgTA0KICAzMTQuMjUwMCA5NC4wMDAwIEwNClMNClUNCnUNCiAgNDEwLjc1MDAgOTEuMDAw MCBtDQogIDQxMC43NTAwIDkxLjAwMDAgTA0KICA0NjQuNTAwMCA5MS4wMDAwIEwNClMNClUN CnUNCiAgNDY0LjUwMDAgOTEuMDAwMCBtDQogIDQ2NS4yNTAwIDkxLjAwMDAgTA0KICA0NjYu MjUwMCA5MC43NTAwIEwNCiAgNDY3LjAwMDAgOTAuNTAwMCBMDQogIDQ2Ny43NTAwIDkwLjI1 MDAgTA0KICA0NjguMjUwMCA4OS43NTAwIEwNCiAgNDY5LjAwMDAgODkuMjUwMCBMDQogIDQ2 OS43NTAwIDg4Ljc1MDAgTA0KICA0NzAuMjUwMCA4OC4yNTAwIEwNCiAgNDcwLjc1MDAgODcu NzUwMCBMDQogIDQ3MS4yNTAwIDg3LjAwMDAgTA0KICA0NzEuNzUwMCA4Ni41MDAwIEwNCiAg NDcyLjAwMDAgODUuNzUwMCBMDQogIDQ3Mi41MDAwIDg1LjAwMDAgTA0KICA0NzIuNzUwMCA4 NC4yNTAwIEwNCiAgNDczLjAwMDAgODMuNTAwMCBMDQogIDQ3My4wMDAwIDgyLjUwMDAgTA0K ICA0NzMuMDAwMCA4Mi41MDAwIEwNCiAgNDczLjAwMDAgODIuNTAwMCBMDQogIDQ3My4wMDAw IDUxLjUwMDAgTA0KUw0KVQ0KdQ0KICAwLjAwMCAwLjAwMCAwLjAwMCAwLjg3MSBrDQogIDQ3 My4wMDAwIDQ4LjUwMDAgbQ0KICA0NzUuNTAwMCA1Mi43NTAwIEwNCiAgNDcwLjUwMDAgNTIu NzUwMCBMDQogIDQ3My4wMDAwIDQ4LjUwMDAgTA0KQg0KVQ0KdQ0KICAwLjAwMCAwLjAwMCAw LjAwMCAwLjg3MSBrDQogIDQ4Ni43NTAwIDQ3LjI1MDAgbQ0KICA0ODkuMjUwMCA1MS41MDAw IEwNCiAgNDg0LjUwMDAgNTEuNTAwMCBMDQogIDQ4Ni43NTAwIDQ3LjI1MDAgTA0KQg0KVQ0K ICAwLjAwMCAwLjAwMCAwLjAwMCAwLjAwMCBrDQogWzEgMiBdIDAgZA0KICAwLjAwMCAwLjAw MCAwLjAwMCAxLjAwMCBLDQp1DQogIDM5Ni41MDAwIDY4MC43NTAwIG0NCiAgNTU4LjAwMDAg NjgwLjc1MDAgTA0KICA1NTguMDAwMCA1NjcuMjUwMCBMDQogIDM5Ni41MDAwIDU2Ny4yNTAw IEwNCiAgMzk2LjUwMDAgNjgwLjc1MDAgTA0KQg0KICA0NzcuMjUwMCA2MjQuMDAwMCBtDQpC DQpVDQp1DQogW10gMCBkDQogIDM4NC41MDAwIDY1MS41MDAwIG0NCiAgMzg0Ljc1MDAgNjUx LjAwMDAgTA0KUw0KVQ0KdQ0KICAzNTYuNTAwMCA2NTEuMDAwMCBtDQogIDM1Ni43NTAwIDY1 MS41MDAwIEwNClMNClUNCnUNCiAgMzcwLjI1MDAgNjA4Ljc1MDAgbQ0KICAzNzAuNTAwMCA2 MDkuMjUwMCBMDQpTDQpVDQp1DQogIDM2OS43NTAwIDYwOC41MDAwIG0NCiAgMzcwLjI1MDAg NjA4Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzNjkuNTAwMCA2MDguNTAwMCBtDQogIDM2OS43NTAw IDYwOC41MDAwIEwNClMNClUNCnUNCiAgMzY5LjAwMDAgNjA4LjI1MDAgbQ0KICAzNjkuNTAw MCA2MDguNTAwMCBMDQpTDQpVDQp1DQogIDM2OC43NTAwIDYwOC4yNTAwIG0NCiAgMzY5LjAw MDAgNjA4LjI1MDAgTA0KUw0KVQ0KdQ0KICAzNjguMjUwMCA2MDguMDAwMCBtDQogIDM2OC43 NTAwIDYwOC4yNTAwIEwNClMNClUNCnUNCiAgMzY3Ljc1MDAgNjA4LjAwMDAgbQ0KICAzNjgu MjUwMCA2MDguMDAwMCBMDQpTDQpVDQp1DQogIDM2Ny41MDAwIDYwOC4wMDAwIG0NCiAgMzY3 Ljc1MDAgNjA4LjAwMDAgTA0KUw0KVQ0KdQ0KICAzNjcuMjUwMCA2MDguMDAwMCBtDQogIDM2 Ny41MDAwIDYwOC4wMDAwIEwNClMNClUNCnUNCiAgMzY2Ljc1MDAgNjA4LjAwMDAgbQ0KICAz NjcuMjUwMCA2MDguMDAwMCBMDQpTDQpVDQp1DQogIDM2Ni41MDAwIDYwOC4wMDAwIG0NCiAg MzY2Ljc1MDAgNjA4LjAwMDAgTA0KUw0KVQ0KdQ0KICAzNjYuMjUwMCA2MDguMDAwMCBtDQog IDM2Ni41MDAwIDYwOC4wMDAwIEwNClMNClUNCnUNCiAgMzY1Ljc1MDAgNjA4LjAwMDAgbQ0K ICAzNjYuMjUwMCA2MDguMDAwMCBMDQpTDQpVDQp1DQogIDM2NS41MDAwIDYwOC4wMDAwIG0N CiAgMzY1Ljc1MDAgNjA4LjAwMDAgTA0KUw0KVQ0KdQ0KICAzNjUuMjUwMCA2MDguMDAwMCBt DQogIDM2NS41MDAwIDYwOC4wMDAwIEwNClMNClUNCnUNCiAgMzY1LjAwMDAgNjA4LjAwMDAg bQ0KICAzNjUuMjUwMCA2MDguMDAwMCBMDQpTDQpVDQp1DQogIDM2NC43NTAwIDYwOC4wMDAw IG0NCiAgMzY1LjAwMDAgNjA4LjAwMDAgTA0KUw0KVQ0KdQ0KICAzNjQuNTAwMCA2MDguMjUw MCBtDQogIDM2NC43NTAwIDYwOC4wMDAwIEwNClMNClUNCnUNCiAgMzY0LjI1MDAgNjA4LjI1 MDAgbQ0KICAzNjQuNTAwMCA2MDguMjUwMCBMDQpTDQpVDQp1DQogIDM2NC4wMDAwIDYwOC41 MDAwIG0NCiAgMzY0LjI1MDAgNjA4LjI1MDAgTA0KUw0KVQ0KdQ0KICAzNjMuNzUwMCA2MDgu NTAwMCBtDQogIDM2NC4wMDAwIDYwOC41MDAwIEwNClMNClUNCnUNCiAgMzYzLjUwMDAgNjA4 LjUwMDAgbQ0KICAzNjMuNzUwMCA2MDguNTAwMCBMDQpTDQpVDQp1DQogIDM2My4yNTAwIDYw OC43NTAwIG0NCiAgMzYzLjUwMDAgNjA4LjUwMDAgTA0KUw0KVQ0KdQ0KICAzNjMuMjUwMCA2 MDkuMDAwMCBtDQogIDM2My4yNTAwIDYwOC43NTAwIEwNClMNClUNCnUNCiAgMzYzLjAwMDAg NjA5LjI1MDAgbQ0KICAzNjMuMjUwMCA2MDkuMDAwMCBMDQpTDQpVDQp1DQogIDM2Mi43NTAw IDYwOS41MDAwIG0NCiAgMzYzLjAwMDAgNjA5LjI1MDAgTA0KUw0KVQ0KdQ0KICAzNjIuNTAw MCA2MDkuNzUwMCBtDQogIDM2Mi41MDAwIDYwOS41MDAwIEwNClMNClUNCnUNCiAgMzYyLjI1 MDAgNjA5Ljc1MDAgbQ0KICAzNjIuNTAwMCA2MDkuNzUwMCBMDQpTDQpVDQp1DQogIDM2Mi4w MDAwIDYxMC4yNTAwIG0NCiAgMzYyLjI1MDAgNjA5Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzNjEu NzUwMCA2MTAuMjUwMCBtDQogIDM2Mi4wMDAwIDYxMC4yNTAwIEwNClMNClUNCnUNCiAgMzYx Ljc1MDAgNjEwLjUwMDAgbQ0KICAzNjEuNzUwMCA2MTAuMjUwMCBMDQpTDQpVDQp1DQogIDM2 MS43NTAwIDYxMC43NTAwIG0NCiAgMzYxLjc1MDAgNjEwLjUwMDAgTA0KUw0KVQ0KdQ0KICAz NjEuNTAwMCA2MTEuMDAwMCBtDQogIDM2MS43NTAwIDYxMC43NTAwIEwNClMNClUNCnUNCiAg MzYxLjI1MDAgNjExLjI1MDAgbQ0KICAzNjEuNTAwMCA2MTEuMDAwMCBMDQpTDQpVDQp1DQog IDM2MS4yNTAwIDYxMS4yNTAwIG0NCiAgMzYxLjI1MDAgNjExLjI1MDAgTA0KUw0KVQ0KdQ0K ICAzNjEuMjUwMCA2MTEuMjUwMCBtDQogIDM2MS41MDAwIDYxMS4yNTAwIEwNClMNClUNCnUN CiAgMzYxLjI1MDAgNjExLjI1MDAgbQ0KICAzNjEuMjUwMCA2MTEuMjUwMCBMDQpTDQpVDQp1 DQogIDM2MS4wMDAwIDYxMS4yNTAwIG0NCiAgMzYxLjI1MDAgNjExLjI1MDAgTA0KUw0KVQ0K dQ0KICAzNjAuNzUwMCA2MTEuMjUwMCBtDQogIDM2MS4wMDAwIDYxMS4yNTAwIEwNClMNClUN CnUNCiAgMzYwLjc1MDAgNjExLjAwMDAgbQ0KICAzNjAuNzUwMCA2MTEuMjUwMCBMDQpTDQpV DQp1DQogIDM2MC41MDAwIDYxMS4wMDAwIG0NCiAgMzYwLjc1MDAgNjExLjAwMDAgTA0KUw0K VQ0KdQ0KICAzNjAuNTAwMCA2MTAuNzUwMCBtDQogIDM2MC41MDAwIDYxMS4wMDAwIEwNClMN ClUNCnUNCiAgMzYwLjI1MDAgNjEwLjUwMDAgbQ0KICAzNjAuNTAwMCA2MTAuNzUwMCBMDQpT DQpVDQp1DQogIDM2MC4yNTAwIDYxMC4yNTAwIG0NCiAgMzYwLjI1MDAgNjEwLjUwMDAgTA0K Uw0KVQ0KdQ0KICAzNTkuNzUwMCA2MTAuMDAwMCBtDQogIDM2MC4yNTAwIDYxMC4yNTAwIEwN ClMNClUNCnUNCiAgMzU5LjUwMDAgNjA5Ljc1MDAgbQ0KICAzNTkuNzUwMCA2MTAuMDAwMCBM DQpTDQpVDQp1DQogIDM1OS4yNTAwIDYwOS41MDAwIG0NCiAgMzU5LjUwMDAgNjA5Ljc1MDAg TA0KUw0KVQ0KdQ0KICAzNTkuMDAwMCA2MDkuMjUwMCBtDQogIDM1OS4yNTAwIDYwOS41MDAw IEwNClMNClUNCnUNCiAgMzU4Ljc1MDAgNjA5LjAwMDAgbQ0KICAzNTkuMDAwMCA2MDkuMjUw MCBMDQpTDQpVDQp1DQogIDM1OC4yNTAwIDYwOC43NTAwIG0NCiAgMzU4Ljc1MDAgNjA5LjAw MDAgTA0KUw0KVQ0KdQ0KICAzNTguMDAwMCA2MDguNTAwMCBtDQogIDM1OC4yNTAwIDYwOC43 NTAwIEwNClMNClUNCnUNCiAgMzU3LjUwMDAgNjA4LjI1MDAgbQ0KICAzNTguMDAwMCA2MDgu NTAwMCBMDQpTDQpVDQp1DQogIDM1Ny4wMDAwIDYwOC4wMDAwIG0NCiAgMzU3LjUwMDAgNjA4 LjI1MDAgTA0KUw0KVQ0KdQ0KICAzNTYuNTAwMCA2MDguMDAwMCBtDQogIDM1Ny4wMDAwIDYw OC4wMDAwIEwNClMNClUNCnUNCiAgMzU2LjAwMDAgNjA3Ljc1MDAgbQ0KICAzNTYuNTAwMCA2 MDguMDAwMCBMDQpTDQpVDQp1DQogIDM1NS41MDAwIDYwNy41MDAwIG0NCiAgMzU2LjAwMDAg NjA3Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzNTUuMDAwMCA2MDcuNTAwMCBtDQogIDM1NS41MDAw IDYwNy41MDAwIEwNClMNClUNCnUNCiAgMzU0LjUwMDAgNjA3LjUwMDAgbQ0KICAzNTUuMDAw MCA2MDcuNTAwMCBMDQpTDQpVDQp1DQogIDM1NC4wMDAwIDYwNy41MDAwIG0NCiAgMzU0LjUw MDAgNjA3LjUwMDAgTA0KUw0KVQ0KdQ0KICAzNTMuNTAwMCA2MDcuMjUwMCBtDQogIDM1NC4w MDAwIDYwNy41MDAwIEwNClMNClUNCnUNCiAgMzUzLjAwMDAgNjA3LjI1MDAgbQ0KICAzNTMu NTAwMCA2MDcuMjUwMCBMDQpTDQpVDQp1DQogIDM1Mi41MDAwIDYwNy4yNTAwIG0NCiAgMzUz LjAwMDAgNjA3LjI1MDAgTA0KUw0KVQ0KdQ0KICAzNTIuMjUwMCA2MDcuMjUwMCBtDQogIDM1 Mi41MDAwIDYwNy4yNTAwIEwNClMNClUNCnUNCiAgMzUxLjUwMDAgNjA3LjI1MDAgbQ0KICAz NTIuMjUwMCA2MDcuMjUwMCBMDQpTDQpVDQp1DQogIDM1MS4yNTAwIDYwNy4yNTAwIG0NCiAg MzUxLjUwMDAgNjA3LjI1MDAgTA0KUw0KVQ0KdQ0KICAzNTAuNzUwMCA2MDcuMjUwMCBtDQog IDM1MS4yNTAwIDYwNy4yNTAwIEwNClMNClUNCnUNCiAgMzUwLjUwMDAgNjA3LjI1MDAgbQ0K ICAzNTAuNzUwMCA2MDcuMjUwMCBMDQpTDQpVDQp1DQogIDM1MC4wMDAwIDYwNy41MDAwIG0N CiAgMzUwLjUwMDAgNjA3LjI1MDAgTA0KUw0KVQ0KdQ0KICAzNDkuNTAwMCA2MDcuNTAwMCBt DQogIDM1MC4wMDAwIDYwNy41MDAwIEwNClMNClUNCnUNCiAgMzQ5LjI1MDAgNjA3LjUwMDAg bQ0KICAzNDkuNTAwMCA2MDcuNTAwMCBMDQpTDQpVDQp1DQogIDM0OC41MDAwIDYwNy43NTAw IG0NCiAgMzQ5LjI1MDAgNjA3LjUwMDAgTA0KUw0KVQ0KdQ0KICAzNDguMjUwMCA2MDguMDAw MCBtDQogIDM0OC41MDAwIDYwNy43NTAwIEwNClMNClUNCnUNCiAgMzQ3Ljc1MDAgNjA4LjI1 MDAgbQ0KICAzNDguMjUwMCA2MDguMDAwMCBMDQpTDQpVDQp1DQogIDM0Ny4yNTAwIDYwOC41 MDAwIG0NCiAgMzQ3Ljc1MDAgNjA4LjI1MDAgTA0KUw0KVQ0KdQ0KICAzNDYuNzUwMCA2MDgu NzUwMCBtDQogIDM0Ny4yNTAwIDYwOC41MDAwIEwNClMNClUNCnUNCiAgMzQ2LjI1MDAgNjA5 LjI1MDAgbQ0KICAzNDYuNzUwMCA2MDguNzUwMCBMDQpTDQpVDQp1DQogIDM0Ni4wMDAwIDYw OS41MDAwIG0NCiAgMzQ2LjI1MDAgNjA5LjI1MDAgTA0KUw0KVQ0KdQ0KICAzNDUuNTAwMCA2 MDkuNzUwMCBtDQogIDM0Ni4wMDAwIDYwOS41MDAwIEwNClMNClUNCnUNCiAgMzQ1LjI1MDAg NjEwLjI1MDAgbQ0KICAzNDUuNTAwMCA2MDkuNzUwMCBMDQpTDQpVDQp1DQogIDM0NS4wMDAw IDYxMC41MDAwIG0NCiAgMzQ1LjI1MDAgNjEwLjI1MDAgTA0KUw0KVQ0KdQ0KICAzNDQuNzUw MCA2MTAuNzUwMCBtDQogIDM0NS4wMDAwIDYxMC41MDAwIEwNClMNClUNCnUNCiAgMzQ0LjUw MDAgNjExLjI1MDAgbQ0KICAzNDQuNzUwMCA2MTAuNzUwMCBMDQpTDQpVDQp1DQogIDM0NC41 MDAwIDYxMS41MDAwIG0NCiAgMzQ0LjUwMDAgNjExLjI1MDAgTA0KUw0KVQ0KdQ0KICAzNDQu MjUwMCA2MTIuMDAwMCBtDQogIDM0NC41MDAwIDYxMS41MDAwIEwNClMNClUNCnUNCiAgMzQ0 LjAwMDAgNjEyLjI1MDAgbQ0KICAzNDQuMjUwMCA2MTIuMDAwMCBMDQpTDQpVDQp1DQogIDM0 NC4wMDAwIDYxMi41MDAwIG0NCiAgMzQ0LjAwMDAgNjEyLjI1MDAgTA0KUw0KVQ0KdQ0KICAz NDQuMDAwMCA2MTIuNzUwMCBtDQogIDM0NC4wMDAwIDYxMi41MDAwIEwNClMNClUNCnUNCiAg MzQzLjc1MDAgNjEzLjAwMDAgbQ0KICAzNDQuMDAwMCA2MTIuNzUwMCBMDQpTDQpVDQp1DQog IDM0My43NTAwIDYxMy41MDAwIG0NCiAgMzQzLjc1MDAgNjEzLjAwMDAgTA0KUw0KVQ0KdQ0K ICAzNDMuNzUwMCA2MTMuNzUwMCBtDQogIDM0My43NTAwIDYxMy41MDAwIEwNClMNClUNCnUN CiAgMzQzLjc1MDAgNjE0LjAwMDAgbQ0KICAzNDMuNzUwMCA2MTMuNzUwMCBMDQpTDQpVDQp1 DQogIDM0My43NTAwIDYxNC4yNTAwIG0NCiAgMzQzLjc1MDAgNjE0LjAwMDAgTA0KUw0KVQ0K dQ0KICAzNDMuNzUwMCA2MTQuNTAwMCBtDQogIDM0My43NTAwIDYxNC4yNTAwIEwNClMNClUN CnUNCiAgMzQzLjc1MDAgNjE0Ljc1MDAgbQ0KICAzNDMuNzUwMCA2MTQuNTAwMCBMDQpTDQpV DQp1DQogIDM0My43NTAwIDYxNS4wMDAwIG0NCiAgMzQzLjc1MDAgNjE0Ljc1MDAgTA0KUw0K VQ0KdQ0KICAzNDMuNzUwMCA2MTUuMjUwMCBtDQogIDM0My43NTAwIDYxNS4wMDAwIEwNClMN ClUNCnUNCiAgMzQzLjc1MDAgNjE1Ljc1MDAgbQ0KICAzNDMuNzUwMCA2MTUuMjUwMCBMDQpT DQpVDQp1DQogIDM0My43NTAwIDYxNS43NTAwIG0NCiAgMzQzLjc1MDAgNjE1Ljc1MDAgTA0K Uw0KVQ0KdQ0KICAzNDMuNzUwMCA2MTYuMjUwMCBtDQogIDM0My43NTAwIDYxNS43NTAwIEwN ClMNClUNCnUNCiAgMzQ0LjAwMDAgNjE2LjUwMDAgbQ0KICAzNDMuNzUwMCA2MTYuMjUwMCBM DQpTDQpVDQp1DQogIDM0NC4wMDAwIDYxNi43NTAwIG0NCiAgMzQ0LjAwMDAgNjE2LjUwMDAg TA0KUw0KVQ0KdQ0KICAzNDQuMDAwMCA2MTcuMDAwMCBtDQogIDM0NC4wMDAwIDYxNi43NTAw IEwNClMNClUNCnUNCiAgMzQ0LjAwMDAgNjE3LjAwMDAgbQ0KICAzNDQuMDAwMCA2MTcuMDAw MCBMDQpTDQpVDQp1DQogIDM0NC4wMDAwIDYxNy41MDAwIG0NCiAgMzQ0LjAwMDAgNjE3LjAw MDAgTA0KUw0KVQ0KdQ0KICAzNDQuMDAwMCA2MTcuNTAwMCBtDQogIDM0NC4wMDAwIDYxNy41 MDAwIEwNClMNClUNCnUNCiAgMzQ0LjI1MDAgNjE3Ljc1MDAgbQ0KICAzNDQuMDAwMCA2MTcu NTAwMCBMDQpTDQpVDQp1DQogIDM0NC4wMDAwIDYxNy43NTAwIG0NCiAgMzQ0LjI1MDAgNjE3 Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzNDQuMDAwMCA2MTguMDAwMCBtDQogIDM0NC4wMDAwIDYx Ny43NTAwIEwNClMNClUNCnUNCiAgMzQ0LjAwMDAgNjE4LjAwMDAgbQ0KICAzNDQuMDAwMCA2 MTguMDAwMCBMDQpTDQpVDQp1DQogIDM0My41MDAwIDYxOC4wMDAwIG0NCiAgMzQ0LjAwMDAg NjE4LjAwMDAgTA0KUw0KVQ0KdQ0KICAzNDMuMjUwMCA2MTguMDAwMCBtDQogIDM0My41MDAw IDYxOC4wMDAwIEwNClMNClUNCnUNCiAgMzQzLjAwMDAgNjE4LjAwMDAgbQ0KICAzNDMuMjUw MCA2MTguMDAwMCBMDQpTDQpVDQp1DQogIDM0Mi41MDAwIDYxNy43NTAwIG0NCiAgMzQzLjAw MDAgNjE4LjAwMDAgTA0KUw0KVQ0KdQ0KICAzNDIuMDAwMCA2MTcuNTAwMCBtDQogIDM0Mi41 MDAwIDYxNy43NTAwIEwNClMNClUNCnUNCiAgMzQxLjUwMDAgNjE3LjUwMDAgbQ0KICAzNDIu MDAwMCA2MTcuNTAwMCBMDQpTDQpVDQp1DQogIDM0MS4wMDAwIDYxNy41MDAwIG0NCiAgMzQx LjUwMDAgNjE3LjUwMDAgTA0KUw0KVQ0KdQ0KICAzNDAuNTAwMCA2MTcuNTAwMCBtDQogIDM0 MS4wMDAwIDYxNy41MDAwIEwNClMNClUNCnUNCiAgMzQwLjAwMDAgNjE3LjI1MDAgbQ0KICAz NDAuNTAwMCA2MTcuNTAwMCBMDQpTDQpVDQp1DQogIDMzOS41MDAwIDYxNy4yNTAwIG0NCiAg MzQwLjAwMDAgNjE3LjI1MDAgTA0KUw0KVQ0KdQ0KICAzMzkuMDAwMCA2MTcuMjUwMCBtDQog IDMzOS41MDAwIDYxNy4yNTAwIEwNClMNClUNCnUNCiAgMzM4LjUwMDAgNjE3LjI1MDAgbQ0K ICAzMzkuMDAwMCA2MTcuMjUwMCBMDQpTDQpVDQp1DQogIDMzOC4wMDAwIDYxNy4yNTAwIG0N CiAgMzM4LjUwMDAgNjE3LjI1MDAgTA0KUw0KVQ0KdQ0KICAzMzcuNTAwMCA2MTcuMjUwMCBt DQogIDMzOC4wMDAwIDYxNy4yNTAwIEwNClMNClUNCnUNCiAgMzM3LjAwMDAgNjE3LjUwMDAg bQ0KICAzMzcuNTAwMCA2MTcuMjUwMCBMDQpTDQpVDQp1DQogIDMzNi41MDAwIDYxNy41MDAw IG0NCiAgMzM3LjAwMDAgNjE3LjUwMDAgTA0KUw0KVQ0KdQ0KICAzMzYuMDAwMCA2MTcuNTAw MCBtDQogIDMzNi41MDAwIDYxNy41MDAwIEwNClMNClUNCnUNCiAgMzM1LjUwMDAgNjE4LjAw MDAgbQ0KICAzMzYuMDAwMCA2MTcuNTAwMCBMDQpTDQpVDQp1DQogIDMzNS4wMDAwIDYxOC4w MDAwIG0NCiAgMzM1LjUwMDAgNjE4LjAwMDAgTA0KUw0KVQ0KdQ0KICAzMzQuNTAwMCA2MTgu NTAwMCBtDQogIDMzNS4wMDAwIDYxOC4wMDAwIEwNClMNClUNCnUNCiAgMzM0LjAwMDAgNjE4 Ljc1MDAgbQ0KICAzMzQuNTAwMCA2MTguNTAwMCBMDQpTDQpVDQp1DQogIDMzMy43NTAwIDYx OS4wMDAwIG0NCiAgMzM0LjAwMDAgNjE4Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzMzMuMjUwMCA2 MTkuMjUwMCBtDQogIDMzMy43NTAwIDYxOS4wMDAwIEwNClMNClUNCnUNCiAgMzMzLjAwMDAg NjE5LjUwMDAgbQ0KICAzMzMuMjUwMCA2MTkuMjUwMCBMDQpTDQpVDQp1DQogIDMzMi41MDAw IDYyMC4wMDAwIG0NCiAgMzMzLjAwMDAgNjE5LjUwMDAgTA0KUw0KVQ0KdQ0KICAzMzIuMjUw MCA2MjAuMjUwMCBtDQogIDMzMi41MDAwIDYyMC4wMDAwIEwNClMNClUNCnUNCiAgMzMyLjAw MDAgNjIwLjUwMDAgbQ0KICAzMzIuMjUwMCA2MjAuMjUwMCBMDQpTDQpVDQp1DQogIDMzMi4w MDAwIDYyMS4wMDAwIG0NCiAgMzMyLjAwMDAgNjIwLjUwMDAgTA0KUw0KVQ0KdQ0KICAzMzEu NzUwMCA2MjEuMjUwMCBtDQogIDMzMi4wMDAwIDYyMS4wMDAwIEwNClMNClUNCnUNCiAgMzMx LjUwMDAgNjIxLjUwMDAgbQ0KICAzMzEuNzUwMCA2MjEuMjUwMCBMDQpTDQpVDQp1DQogIDMz MS41MDAwIDYyMi4wMDAwIG0NCiAgMzMxLjUwMDAgNjIxLjUwMDAgTA0KUw0KVQ0KdQ0KICAz MzEuNTAwMCA2MjIuMjUwMCBtDQogIDMzMS41MDAwIDYyMi4wMDAwIEwNClMNClUNCnUNCiAg MzMxLjI1MDAgNjIyLjc1MDAgbQ0KICAzMzEuNTAwMCA2MjIuMjUwMCBMDQpTDQpVDQp1DQog IDMzMS4yNTAwIDYyMy4wMDAwIG0NCiAgMzMxLjI1MDAgNjIyLjc1MDAgTA0KUw0KVQ0KdQ0K ICAzMzEuMjUwMCA2MjMuMjUwMCBtDQogIDMzMS4yNTAwIDYyMy4wMDAwIEwNClMNClUNCnUN CiAgMzMxLjI1MDAgNjIzLjc1MDAgbQ0KICAzMzEuMjUwMCA2MjMuMjUwMCBMDQpTDQpVDQp1 DQogIDMzMS41MDAwIDYyNC4wMDAwIG0NCiAgMzMxLjI1MDAgNjIzLjc1MDAgTA0KUw0KVQ0K dQ0KICAzMzEuNTAwMCA2MjQuMjUwMCBtDQogIDMzMS41MDAwIDYyNC4wMDAwIEwNClMNClUN CnUNCiAgMzMxLjUwMDAgNjI0Ljc1MDAgbQ0KICAzMzEuNTAwMCA2MjQuMjUwMCBMDQpTDQpV DQp1DQogIDMzMS41MDAwIDYyNS4wMDAwIG0NCiAgMzMxLjUwMDAgNjI0Ljc1MDAgTA0KUw0K VQ0KdQ0KICAzMzEuNzUwMCA2MjUuMjUwMCBtDQogIDMzMS41MDAwIDYyNS4wMDAwIEwNClMN ClUNCnUNCiAgMzMxLjc1MDAgNjI1LjUwMDAgbQ0KICAzMzEuNzUwMCA2MjUuMjUwMCBMDQpT DQpVDQp1DQogIDMzMi4wMDAwIDYyNS43NTAwIG0NCiAgMzMxLjc1MDAgNjI1LjUwMDAgTA0K Uw0KVQ0KdQ0KICAzMzIuMDAwMCA2MjYuMDAwMCBtDQogIDMzMi4wMDAwIDYyNS43NTAwIEwN ClMNClUNCnUNCiAgMzMyLjAwMDAgNjI2LjI1MDAgbQ0KICAzMzIuMDAwMCA2MjYuMDAwMCBM DQpTDQpVDQp1DQogIDMzMi4yNTAwIDYyNi43NTAwIG0NCiAgMzMyLjAwMDAgNjI2LjI1MDAg TA0KUw0KVQ0KdQ0KICAzMzIuMjUwMCA2MjYuNzUwMCBtDQogIDMzMi4yNTAwIDYyNi43NTAw IEwNClMNClUNCnUNCiAgMzMyLjUwMDAgNjI3LjAwMDAgbQ0KICAzMzIuMjUwMCA2MjYuNzUw MCBMDQpTDQpVDQp1DQogIDMzMi43NTAwIDYyNy4yNTAwIG0NCiAgMzMyLjUwMDAgNjI3LjAw MDAgTA0KUw0KVQ0KdQ0KICAzMzMuMDAwMCA2MjcuNTAwMCBtDQogIDMzMi43NTAwIDYyNy4y NTAwIEwNClMNClUNCnUNCiAgMzMzLjAwMDAgNjI3Ljc1MDAgbQ0KICAzMzMuMDAwMCA2Mjcu NTAwMCBMDQpTDQpVDQp1DQogIDMzMy4yNTAwIDYyOC4wMDAwIG0NCiAgMzMzLjAwMDAgNjI3 Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzMzMuNTAwMCA2MjguMjUwMCBtDQogIDMzMy4yNTAwIDYy OC4wMDAwIEwNClMNClUNCnUNCiAgMzMzLjc1MDAgNjI4LjUwMDAgbQ0KICAzMzMuNTAwMCA2 MjguMjUwMCBMDQpTDQpVDQp1DQogIDMzNC4wMDAwIDYyOC43NTAwIG0NCiAgMzMzLjc1MDAg NjI4LjUwMDAgTA0KUw0KVQ0KdQ0KICAzMzQuMjUwMCA2MjkuMjUwMCBtDQogIDMzNC4wMDAw IDYyOC43NTAwIEwNClMNClUNCnUNCiAgMzM0LjUwMDAgNjI5LjUwMDAgbQ0KICAzMzQuMjUw MCA2MjkuMjUwMCBMDQpTDQpVDQp1DQogIDMzNC43NTAwIDYyOS41MDAwIG0NCiAgMzM0LjUw MDAgNjI5LjUwMDAgTA0KUw0KVQ0KdQ0KICAzMzUuMDAwMCA2MzAuMDAwMCBtDQogIDMzNC43 NTAwIDYyOS41MDAwIEwNClMNClUNCnUNCiAgMzM1LjI1MDAgNjMwLjAwMDAgbQ0KICAzMzUu MDAwMCA2MzAuMDAwMCBMDQpTDQpVDQp1DQogIDMzNS41MDAwIDYzMC4yNTAwIG0NCiAgMzM1 LjI1MDAgNjMwLjAwMDAgTA0KUw0KVQ0KdQ0KICAzMzUuNzUwMCA2MzAuNTAwMCBtDQogIDMz NS41MDAwIDYzMC4yNTAwIEwNClMNClUNCnUNCiAgMzM1Ljc1MDAgNjMwLjc1MDAgbQ0KICAz MzUuNzUwMCA2MzAuNTAwMCBMDQpTDQpVDQp1DQogIDMzNS43NTAwIDYzMS4wMDAwIG0NCiAg MzM1Ljc1MDAgNjMwLjc1MDAgTA0KUw0KVQ0KdQ0KICAzMzUuNzUwMCA2MzEuMDAwMCBtDQog IDMzNS43NTAwIDYzMS4wMDAwIEwNClMNClUNCnUNCiAgMzM1LjUwMDAgNjMxLjI1MDAgbQ0K ICAzMzUuNzUwMCA2MzEuMDAwMCBMDQpTDQpVDQp1DQogIDMzNS4yNTAwIDYzMS41MDAwIG0N CiAgMzM1LjUwMDAgNjMxLjI1MDAgTA0KUw0KVQ0KdQ0KICAzMzUuMDAwMCA2MzEuNTAwMCBt DQogIDMzNS4yNTAwIDYzMS41MDAwIEwNClMNClUNCnUNCiAgMzM0Ljc1MDAgNjMxLjc1MDAg bQ0KICAzMzUuMDAwMCA2MzEuNzUwMCBMDQpTDQpVDQp1DQogIDMzNC4yNTAwIDYzMi4wMDAw IG0NCiAgMzM0Ljc1MDAgNjMxLjc1MDAgTA0KUw0KVQ0KdQ0KICAzMzQuMDAwMCA2MzIuMjUw MCBtDQogIDMzNC4yNTAwIDYzMi4wMDAwIEwNClMNClUNCnUNCiAgMzMzLjUwMDAgNjMyLjI1 MDAgbQ0KICAzMzQuMDAwMCA2MzIuMjUwMCBMDQpTDQpVDQp1DQogIDMzMy4yNTAwIDYzMi43 NTAwIG0NCiAgMzMzLjUwMDAgNjMyLjI1MDAgTA0KUw0KVQ0KdQ0KICAzMzMuMDAwMCA2MzMu MDAwMCBtDQogIDMzMy4yNTAwIDYzMi43NTAwIEwNClMNClUNCnUNCiAgMzMyLjc1MDAgNjMz LjI1MDAgbQ0KICAzMzMuMDAwMCA2MzMuMDAwMCBMDQpTDQpVDQp1DQogIDMzMi4yNTAwIDYz My41MDAwIG0NCiAgMzMyLjc1MDAgNjMzLjI1MDAgTA0KUw0KVQ0KdQ0KICAzMzIuMDAwMCA2 MzQuMDAwMCBtDQogIDMzMi4yNTAwIDYzMy41MDAwIEwNClMNClUNCnUNCiAgMzMyLjAwMDAg NjM0LjI1MDAgbQ0KICAzMzIuMDAwMCA2MzQuMDAwMCBMDQpTDQpVDQp1DQogIDMzMS43NTAw IDYzNC41MDAwIG0NCiAgMzMyLjAwMDAgNjM0LjI1MDAgTA0KUw0KVQ0KdQ0KICAzMzEuNTAw MCA2MzUuMDAwMCBtDQogIDMzMS43NTAwIDYzNC41MDAwIEwNClMNClUNCnUNCiAgMzMxLjUw MDAgNjM1LjUwMDAgbQ0KICAzMzEuNTAwMCA2MzUuMDAwMCBMDQpTDQpVDQp1DQogIDMzMS41 MDAwIDYzNS43NTAwIG0NCiAgMzMxLjUwMDAgNjM1LjUwMDAgTA0KUw0KVQ0KdQ0KICAzMzEu NTAwMCA2MzYuMjUwMCBtDQogIDMzMS41MDAwIDYzNS43NTAwIEwNClMNClUNCnUNCiAgMzMx LjUwMDAgNjM2Ljc1MDAgbQ0KICAzMzEuNTAwMCA2MzYuMjUwMCBMDQpTDQpVDQp1DQogIDMz MS41MDAwIDYzNy4yNTAwIG0NCiAgMzMxLjUwMDAgNjM2Ljc1MDAgTA0KUw0KVQ0KdQ0KICAz MzEuNTAwMCA2MzcuNzUwMCBtDQogIDMzMS41MDAwIDYzNy4yNTAwIEwNClMNClUNCnUNCiAg MzMxLjc1MDAgNjM4LjI1MDAgbQ0KICAzMzEuNTAwMCA2MzcuNzUwMCBMDQpTDQpVDQp1DQog IDMzMi4wMDAwIDYzOC43NTAwIG0NCiAgMzMxLjc1MDAgNjM4LjI1MDAgTA0KUw0KVQ0KdQ0K ICAzMzIuMjUwMCA2MzkuMjUwMCBtDQogIDMzMi4wMDAwIDYzOC43NTAwIEwNClMNClUNCnUN CiAgMzMyLjI1MDAgNjM5LjUwMDAgbQ0KICAzMzIuMjUwMCA2MzkuMjUwMCBMDQpTDQpVDQp1 DQogIDMzMi43NTAwIDY0MC4wMDAwIG0NCiAgMzMyLjI1MDAgNjM5LjUwMDAgTA0KUw0KVQ0K dQ0KICAzMzMuMDAwMCA2NDAuMjUwMCBtDQogIDMzMi43NTAwIDY0MC4wMDAwIEwNClMNClUN CnUNCiAgMzMzLjI1MDAgNjQwLjc1MDAgbQ0KICAzMzMuMDAwMCA2NDAuMjUwMCBMDQpTDQpV DQp1DQogIDMzMy41MDAwIDY0MS4yNTAwIG0NCiAgMzMzLjI1MDAgNjQwLjc1MDAgTA0KUw0K VQ0KdQ0KICAzMzQuMDAwMCA2NDEuNTAwMCBtDQogIDMzMy41MDAwIDY0MS4yNTAwIEwNClMN ClUNCnUNCiAgMzM0LjI1MDAgNjQxLjc1MDAgbQ0KICAzMzQuMDAwMCA2NDEuNTAwMCBMDQpT DQpVDQp1DQogIDMzNC43NTAwIDY0Mi4wMDAwIG0NCiAgMzM0LjI1MDAgNjQxLjc1MDAgTA0K Uw0KVQ0KdQ0KICAzMzUuMDAwMCA2NDIuMjUwMCBtDQogIDMzNC43NTAwIDY0Mi4wMDAwIEwN ClMNClUNCnUNCiAgMzM1LjI1MDAgNjQyLjUwMDAgbQ0KICAzMzUuMDAwMCA2NDIuMjUwMCBM DQpTDQpVDQp1DQogIDMzNS43NTAwIDY0Mi43NTAwIG0NCiAgMzM1LjI1MDAgNjQyLjUwMDAg TA0KUw0KVQ0KdQ0KICAzMzYuMDAwMCA2NDIuNzUwMCBtDQogIDMzNS43NTAwIDY0Mi43NTAw IEwNClMNClUNCnUNCiAgMzM2LjUwMDAgNjQzLjAwMDAgbQ0KICAzMzYuMDAwMCA2NDIuNzUw MCBMDQpTDQpVDQp1DQogIDMzNi43NTAwIDY0My4wMDAwIG0NCiAgMzM2LjUwMDAgNjQzLjAw MDAgTA0KUw0KVQ0KdQ0KICAzMzcuMjUwMCA2NDMuMDAwMCBtDQogIDMzNi43NTAwIDY0My4w MDAwIEwNClMNClUNCnUNCiAgMzM3LjUwMDAgNjQzLjAwMDAgbQ0KICAzMzcuMjUwMCA2NDMu MDAwMCBMDQpTDQpVDQp1DQogIDMzOC4wMDAwIDY0My4yNTAwIG0NCiAgMzM3LjUwMDAgNjQz LjAwMDAgTA0KUw0KVQ0KdQ0KICAzMzguMjUwMCA2NDMuMjUwMCBtDQogIDMzOC4wMDAwIDY0 My4yNTAwIEwNClMNClUNCnUNCiAgMzM4LjUwMDAgNjQzLjI1MDAgbQ0KICAzMzguMjUwMCA2 NDMuMjUwMCBMDQpTDQpVDQp1DQogIDMzOC43NTAwIDY0My41MDAwIG0NCiAgMzM4LjUwMDAg NjQzLjI1MDAgTA0KUw0KVQ0KdQ0KICAzMzkuMDAwMCA2NDMuNTAwMCBtDQogIDMzOC43NTAw IDY0My41MDAwIEwNClMNClUNCnUNCiAgMzM5LjI1MDAgNjQzLjc1MDAgbQ0KICAzMzkuMDAw MCA2NDMuNTAwMCBMDQpTDQpVDQp1DQogIDMzOS41MDAwIDY0My43NTAwIG0NCiAgMzM5LjI1 MDAgNjQzLjc1MDAgTA0KUw0KVQ0KdQ0KICAzMzkuNTAwMCA2NDQuMDAwMCBtDQogIDMzOS41 MDAwIDY0My43NTAwIEwNClMNClUNCnUNCiAgMzM5Ljc1MDAgNjQ0LjAwMDAgbQ0KICAzMzku NTAwMCA2NDQuMDAwMCBMDQpTDQpVDQp1DQogIDMzOS43NTAwIDY0NC4yNTAwIG0NCiAgMzM5 Ljc1MDAgNjQ0LjAwMDAgTA0KUw0KVQ0KdQ0KICAzMzkuNzUwMCA2NDQuNTAwMCBtDQogIDMz OS43NTAwIDY0NC4yNTAwIEwNClMNClUNCnUNCiAgMzM5Ljc1MDAgNjQ0Ljc1MDAgbQ0KICAz MzkuNzUwMCA2NDQuNTAwMCBMDQpTDQpVDQp1DQogIDM0MC4wMDAwIDY0NS4wMDAwIG0NCiAg MzM5Ljc1MDAgNjQ0Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzNDAuMDAwMCA2NDUuMjUwMCBtDQog IDM0MC4wMDAwIDY0NS4wMDAwIEwNClMNClUNCnUNCiAgMzQwLjAwMDAgNjQ1Ljc1MDAgbQ0K ICAzNDAuMDAwMCA2NDUuMjUwMCBMDQpTDQpVDQp1DQogIDM0MC4wMDAwIDY0Ni4wMDAwIG0N CiAgMzQwLjAwMDAgNjQ1Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzNDAuMjUwMCA2NDYuMjUwMCBt DQogIDM0MC4wMDAwIDY0Ni4wMDAwIEwNClMNClUNCnUNCiAgMzQwLjUwMDAgNjQ2LjUwMDAg bQ0KICAzNDAuMjUwMCA2NDYuMjUwMCBMDQpTDQpVDQp1DQogIDM0MC41MDAwIDY0Ny4wMDAw IG0NCiAgMzQwLjUwMDAgNjQ2LjUwMDAgTA0KUw0KVQ0KdQ0KICAzNDAuNzUwMCA2NDcuNTAw MCBtDQogIDM0MC41MDAwIDY0Ny4wMDAwIEwNClMNClUNCnUNCiAgMzQxLjAwMDAgNjQ3Ljc1 MDAgbQ0KICAzNDAuNzUwMCA2NDcuNTAwMCBMDQpTDQpVDQp1DQogIDM0MS4yNTAwIDY0OC4y NTAwIG0NCiAgMzQxLjAwMDAgNjQ3Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzNDEuNTAwMCA2NDgu NTAwMCBtDQogIDM0MS4yNTAwIDY0OC4yNTAwIEwNClMNClUNCnUNCiAgMzQxLjc1MDAgNjQ4 Ljc1MDAgbQ0KICAzNDEuNTAwMCA2NDguNTAwMCBMDQpTDQpVDQp1DQogIDM0MS43NTAwIDY0 OC43NTAwIG0NCiAgMzQyLjI1MDAgNjQ5LjAwMDAgTA0KUw0KVQ0KdQ0KICAzNDIuMjUwMCA2 NDkuMDAwMCBtDQogIDM0Mi41MDAwIDY0OS4yNTAwIEwNClMNClUNCnUNCiAgMzQyLjUwMDAg NjQ5LjI1MDAgbQ0KICAzNDMuMDAwMCA2NDkuNTAwMCBMDQpTDQpVDQp1DQogIDM0My4wMDAw IDY0OS41MDAwIG0NCiAgMzQzLjI1MDAgNjQ5Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzNDMuMjUw MCA2NDkuNzUwMCBtDQogIDM0My43NTAwIDY1MC4wMDAwIEwNClMNClUNCnUNCiAgMzQzLjc1 MDAgNjUwLjAwMDAgbQ0KICAzNDQuMjUwMCA2NTAuMjUwMCBMDQpTDQpVDQp1DQogIDM0NC4y NTAwIDY1MC4wMDAwIG0NCiAgMzQ0Ljc1MDAgNjUwLjI1MDAgTA0KUw0KVQ0KdQ0KICAzNDQu NzUwMCA2NTAuMjUwMCBtDQogIDM0NS4yNTAwIDY1MC4yNTAwIEwNClMNClUNCnUNCiAgMzQ1 LjI1MDAgNjUwLjI1MDAgbQ0KICAzNDUuNzUwMCA2NTAuNTAwMCBMDQpTDQpVDQp1DQogIDM0 NS43NTAwIDY1MC41MDAwIG0NCiAgMzQ2LjI1MDAgNjUwLjUwMDAgTA0KUw0KVQ0KdQ0KICAz NDYuMjUwMCA2NTAuNTAwMCBtDQogIDM0Ny4wMDAwIDY1MC41MDAwIEwNClMNClUNCnUNCiAg MzQ3LjAwMDAgNjUwLjUwMDAgbQ0KICAzNDcuNTAwMCA2NTAuNTAwMCBMDQpTDQpVDQp1DQog IDM0Ny41MDAwIDY1MC41MDAwIG0NCiAgMzQ4LjI1MDAgNjUwLjUwMDAgTA0KUw0KVQ0KdQ0K ICAzNDguMjUwMCA2NTAuNTAwMCBtDQogIDM0OC43NTAwIDY1MC4yNTAwIEwNClMNClUNCnUN CiAgMzQ4Ljc1MDAgNjUwLjI1MDAgbQ0KICAzNDkuNTAwMCA2NTAuMjUwMCBMDQpTDQpVDQp1 DQogIDM0OS41MDAwIDY1MC4yNTAwIG0NCiAgMzUwLjI1MDAgNjUwLjAwMDAgTA0KUw0KVQ0K dQ0KICAzNTAuMjUwMCA2NTAuMjUwMCBtDQogIDM1MS4wMDAwIDY1MC4wMDAwIEwNClMNClUN CnUNCiAgMzUxLjAwMDAgNjUwLjAwMDAgbQ0KICAzNTEuNTAwMCA2NDkuNzUwMCBMDQpTDQpV DQp1DQogIDM1MS41MDAwIDY0OS43NTAwIG0NCiAgMzUyLjI1MDAgNjQ5Ljc1MDAgTA0KUw0K VQ0KdQ0KICAzNTIuMjUwMCA2NDkuNzUwMCBtDQogIDM1Mi43NTAwIDY0OS41MDAwIEwNClMN ClUNCnUNCiAgMzUyLjc1MDAgNjQ5LjUwMDAgbQ0KICAzNTMuMjUwMCA2NDkuNTAwMCBMDQpT DQpVDQp1DQogIDM1My4yNTAwIDY0OS41MDAwIG0NCiAgMzUzLjc1MDAgNjQ5LjI1MDAgTA0K Uw0KVQ0KdQ0KICAzNTMuNzUwMCA2NDkuMjUwMCBtDQogIDM1NC4yNTAwIDY0OS4yNTAwIEwN ClMNClUNCnUNCiAgMzU0LjI1MDAgNjQ5LjI1MDAgbQ0KICAzNTQuNTAwMCA2NDkuNTAwMCBM DQpTDQpVDQp1DQogIDM1NC41MDAwIDY0OS41MDAwIG0NCiAgMzU0Ljc1MDAgNjQ5LjUwMDAg TA0KUw0KVQ0KdQ0KICAzNTQuNzUwMCA2NDkuNTAwMCBtDQogIDM1NS4wMDAwIDY0OS43NTAw IEwNClMNClUNCnUNCiAgMzU1LjAwMDAgNjQ5Ljc1MDAgbQ0KICAzNTUuMjUwMCA2NTAuMDAw MCBMDQpTDQpVDQp1DQogIDM1NS4yNTAwIDY1MC4wMDAwIG0NCiAgMzU1LjUwMDAgNjUwLjI1 MDAgTA0KUw0KVQ0KdQ0KICAzNTUuNTAwMCA2NTAuMjUwMCBtDQogIDM1NS43NTAwIDY1MC41 MDAwIEwNClMNClUNCnUNCiAgMzU1Ljc1MDAgNjUwLjUwMDAgbQ0KICAzNTYuMDAwMCA2NTAu NzUwMCBMDQpTDQpVDQp1DQogIDM1Ni4wMDAwIDY1MC43NTAwIG0NCiAgMzU2LjI1MDAgNjUx LjAwMDAgTA0KUw0KVQ0KdQ0KICAzODQuNzUwMCA2NTEuMDAwMCBtDQogIDM4NC43NTAwIDY1 MC41MDAwIEwNClMNClUNCnUNCiAgMzg0Ljc1MDAgNjUwLjUwMDAgbQ0KICAzODUuMDAwMCA2 NTAuMDAwMCBMDQpTDQpVDQp1DQogIDM4NS4wMDAwIDY1MC4wMDAwIG0NCiAgMzg1LjI1MDAg NjQ5LjUwMDAgTA0KUw0KVQ0KdQ0KICAzODUuMjUwMCA2NDkuNTAwMCBtDQogIDM4NS4yNTAw IDY0OS4yNTAwIEwNClMNClUNCnUNCiAgMzg1LjI1MDAgNjQ5LjI1MDAgbQ0KICAzODUuMjUw MCA2NDguNzUwMCBMDQpTDQpVDQp1DQogIDM4NS4yNTAwIDY0OC43NTAwIG0NCiAgMzg1LjUw MDAgNjQ4LjI1MDAgTA0KUw0KVQ0KdQ0KICAzODUuNTAwMCA2NDcuNTAwMCBtDQogIDM4NS41 MDAwIDY0OC4yNTAwIEwNClMNClUNCnUNCiAgMzg1LjI1MDAgNjQ3LjAwMDAgbQ0KICAzODUu NTAwMCA2NDcuNTAwMCBMDQpTDQpVDQp1DQogIDM4NS4yNTAwIDY0Ni41MDAwIG0NCiAgMzg1 LjI1MDAgNjQ3LjAwMDAgTA0KUw0KVQ0KdQ0KICAzODUuMjUwMCA2NDYuMDAwMCBtDQogIDM4 NS4yNTAwIDY0Ni41MDAwIEwNClMNClUNCnUNCiAgMzg1LjI1MDAgNjQ1LjUwMDAgbQ0KICAz ODUuMjUwMCA2NDYuMDAwMCBMDQpTDQpVDQp1DQogIDM4NS4wMDAwIDY0NS4wMDAwIG0NCiAg Mzg1LjI1MDAgNjQ1LjUwMDAgTA0KUw0KVQ0KdQ0KICAzODUuMDAwMCA2NDQuNTAwMCBtDQog IDM4NS4wMDAwIDY0NS4wMDAwIEwNClMNClUNCnUNCiAgMzg0Ljc1MDAgNjQ0LjAwMDAgbQ0K ICAzODUuMDAwMCA2NDQuNTAwMCBMDQpTDQpVDQp1DQogIDM4NC43NTAwIDY0My41MDAwIG0N CiAgMzg0Ljc1MDAgNjQ0LjAwMDAgTA0KUw0KVQ0KdQ0KICAzODQuNzUwMCA2NDMuMDAwMCBt DQogIDM4NC43NTAwIDY0My41MDAwIEwNClMNClUNCnUNCiAgMzg0Ljc1MDAgNjQzLjAwMDAg bQ0KICAzODQuNzUwMCA2NDMuMDAwMCBMDQpTDQpVDQp1DQogIDM4NC43NTAwIDY0My4wMDAw IG0NCiAgMzg0Ljc1MDAgNjQyLjc1MDAgTA0KUw0KVQ0KdQ0KICAzODQuNzUwMCA2NDIuNzUw MCBtDQogIDM4NC43NTAwIDY0Mi41MDAwIEwNClMNClUNCnUNCiAgMzg0Ljc1MDAgNjQyLjUw MDAgbQ0KICAzODUuMDAwMCA2NDIuMjUwMCBMDQpTDQpVDQp1DQogIDM4NS4wMDAwIDY0Mi4y NTAwIG0NCiAgMzg1LjI1MDAgNjQyLjI1MDAgTA0KUw0KVQ0KdQ0KICAzODUuMjUwMCA2NDIu MjUwMCBtDQogIDM4NS41MDAwIDY0Mi4yNTAwIEwNClMNClUNCnUNCiAgMzg1LjUwMDAgNjQy LjI1MDAgbQ0KICAzODUuNTAwMCA2NDIuMjUwMCBMDQpTDQpVDQp1DQogIDM4NS41MDAwIDY0 Mi4yNTAwIG0NCiAgMzg1Ljc1MDAgNjQyLjI1MDAgTA0KUw0KVQ0KdQ0KICAzODUuNzUwMCA2 NDIuMjUwMCBtDQogIDM4Ni4yNTAwIDY0Mi41MDAwIEwNClMNClUNCnUNCiAgMzg2LjI1MDAg NjQyLjUwMDAgbQ0KICAzODYuNTAwMCA2NDIuNTAwMCBMDQpTDQpVDQp1DQogIDM4Ni41MDAw IDY0Mi41MDAwIG0NCiAgMzg2Ljc1MDAgNjQyLjUwMDAgTA0KUw0KVQ0KdQ0KICAzODYuNzUw MCA2NDIuNTAwMCBtDQogIDM4Ny4wMDAwIDY0Mi41MDAwIEwNClMNClUNCnUNCiAgMzg3LjAw MDAgNjQyLjUwMDAgbQ0KICAzODcuNTAwMCA2NDIuNTAwMCBMDQpTDQpVDQp1DQogIDM4Ny41 MDAwIDY0Mi41MDAwIG0NCiAgMzg3Ljc1MDAgNjQyLjc1MDAgTA0KUw0KVQ0KdQ0KICAzODcu NzUwMCA2NDIuNzUwMCBtDQogIDM4OC4wMDAwIDY0Mi43NTAwIEwNClMNClUNCnUNCiAgMzg4 LjAwMDAgNjQyLjc1MDAgbQ0KICAzODguNTAwMCA2NDIuNzUwMCBMDQpTDQpVDQp1DQogIDM4 OC41MDAwIDY0Mi43NTAwIG0NCiAgMzg4Ljc1MDAgNjQyLjc1MDAgTA0KUw0KVQ0KdQ0KICAz ODguNzUwMCA2NDIuNzUwMCBtDQogIDM4OS4yNTAwIDY0Mi43NTAwIEwNClMNClUNCnUNCiAg Mzg5LjI1MDAgNjQyLjc1MDAgbQ0KICAzODkuNTAwMCA2NDIuNTAwMCBMDQpTDQpVDQp1DQog IDM4OS41MDAwIDY0Mi41MDAwIG0NCiAgMzg5Ljc1MDAgNjQyLjUwMDAgTA0KUw0KVQ0KdQ0K ICAzODkuNzUwMCA2NDIuNTAwMCBtDQogIDM5MC4wMDAwIDY0Mi41MDAwIEwNClMNClUNCnUN CiAgMzkwLjAwMDAgNjQyLjUwMDAgbQ0KICAzOTAuNTAwMCA2NDIuMjUwMCBMDQpTDQpVDQp1 DQogIDM5MC41MDAwIDY0Mi4yNTAwIG0NCiAgMzkwLjc1MDAgNjQyLjAwMDAgTA0KUw0KVQ0K dQ0KICAzOTAuNzUwMCA2NDIuMDAwMCBtDQogIDM5MS4wMDAwIDY0Mi4wMDAwIEwNClMNClUN CnUNCiAgMzkxLjAwMDAgNjQyLjAwMDAgbQ0KICAzOTEuMjUwMCA2NDEuNzUwMCBMDQpTDQpV DQp1DQogIDM5MS4yNTAwIDY0MS43NTAwIG0NCiAgMzkxLjUwMDAgNjQxLjUwMDAgTA0KUw0K VQ0KdQ0KICAzOTEuNTAwMCA2NDEuNTAwMCBtDQogIDM5MS43NTAwIDY0MS4yNTAwIEwNClMN ClUNCnUNCiAgMzkxLjc1MDAgNjQxLjI1MDAgbQ0KICAzOTEuNzUwMCA2NDEuMDAwMCBMDQpT DQpVDQp1DQogIDM5MS43NTAwIDY0MS4wMDAwIG0NCiAgMzkyLjAwMDAgNjQwLjUwMDAgTA0K Uw0KVQ0KdQ0KICAzOTIuMDAwMCA2NDAuNTAwMCBtDQogIDM5Mi4wMDAwIDY0MC4yNTAwIEwN ClMNClUNCnUNCiAgMzkyLjAwMDAgNjQwLjI1MDAgbQ0KICAzOTIuMjUwMCA2NDAuMDAwMCBM DQpTDQpVDQp1DQogIDM5Mi4yNTAwIDY0MC4wMDAwIG0NCiAgMzkyLjI1MDAgNjM5LjUwMDAg TA0KUw0KVQ0KdQ0KICAzOTIuMjUwMCA2MzkuNTAwMCBtDQogIDM5Mi41MDAwIDYzOS4yNTAw IEwNClMNClUNCnUNCiAgMzkyLjUwMDAgNjM5LjI1MDAgbQ0KICAzOTIuNTAwMCA2MzguNzUw MCBMDQpTDQpVDQp1DQogIDM5Mi41MDAwIDYzOC43NTAwIG0NCiAgMzkyLjUwMDAgNjM4LjUw MDAgTA0KUw0KVQ0KdQ0KICAzOTIuNTAwMCA2MzguMDAwMCBtDQogIDM5Mi41MDAwIDYzOC41 MDAwIEwNClMNClUNCnUNCiAgMzkyLjUwMDAgNjM3LjUwMDAgbQ0KICAzOTIuNTAwMCA2Mzgu MDAwMCBMDQpTDQpVDQp1DQogIDM5Mi41MDAwIDYzNy4yNTAwIG0NCiAgMzkyLjUwMDAgNjM3 LjUwMDAgTA0KUw0KVQ0KdQ0KICAzOTIuNTAwMCA2MzcuMjUwMCBtDQogIDM5Mi41MDAwIDYz Ni43NTAwIEwNClMNClUNCnUNCiAgMzkyLjUwMDAgNjM2Ljc1MDAgbQ0KICAzOTIuNTAwMCA2 MzYuNTAwMCBMDQpTDQpVDQp1DQogIDM5Mi41MDAwIDYzNi41MDAwIG0NCiAgMzkyLjc1MDAg NjM2LjI1MDAgTA0KUw0KVQ0KdQ0KICAzOTIuNzUwMCA2MzYuMjUwMCBtDQogIDM5Mi43NTAw IDYzNS43NTAwIEwNClMNClUNCnUNCiAgMzkzLjAwMDAgNjM1Ljc1MDAgbQ0KICAzOTIuNzUw MCA2MzUuNzUwMCBMDQpTDQpVDQp1DQogIDM5My4yNTAwIDYzNS41MDAwIG0NCiAgMzkzLjAw MDAgNjM1Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzOTMuNzUwMCA2MzUuMjUwMCBtDQogIDM5My4y NTAwIDYzNS41MDAwIEwNClMNClUNCnUNCiAgMzk0LjAwMDAgNjM1LjI1MDAgbQ0KICAzOTMu NzUwMCA2MzUuMjUwMCBMDQpTDQpVDQp1DQogIDM5NC41MDAwIDYzNS4wMDAwIG0NCiAgMzk0 LjAwMDAgNjM1LjI1MDAgTA0KUw0KVQ0KdQ0KICAzOTUuMDAwMCA2MzQuNzUwMCBtDQogIDM5 NC41MDAwIDYzNS4wMDAwIEwNClMNClUNCnUNCiAgMzk1LjUwMDAgNjM0Ljc1MDAgbQ0KICAz OTUuMDAwMCA2MzQuNzUwMCBMDQpTDQpVDQp1DQogIDM5NS43NTAwIDYzNC41MDAwIG0NCiAg Mzk1LjUwMDAgNjM0Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzOTYuMjUwMCA2MzQuMjUwMCBtDQog IDM5NS43NTAwIDYzNC41MDAwIEwNClMNClUNCnUNCiAgMzk2Ljc1MDAgNjM0LjAwMDAgbQ0K ICAzOTYuMjUwMCA2MzQuMjUwMCBMDQpTDQpVDQp1DQogIDM5Ny4yNTAwIDYzNC4wMDAwIG0N CiAgMzk2Ljc1MDAgNjM0LjAwMDAgTA0KUw0KVQ0KdQ0KICAzOTcuNzUwMCA2MzMuNTAwMCBt DQogIDM5Ny4yNTAwIDYzNC4wMDAwIEwNClMNClUNCnUNCiAgMzk4LjI1MDAgNjMzLjI1MDAg bQ0KICAzOTcuNzUwMCA2MzMuNTAwMCBMDQpTDQpVDQp1DQogIDM5OC43NTAwIDYzMy4wMDAw IG0NCiAgMzk4LjI1MDAgNjMzLjI1MDAgTA0KUw0KVQ0KdQ0KICAzOTkuMjUwMCA2MzIuNzUw MCBtDQogIDM5OC43NTAwIDYzMy4wMDAwIEwNClMNClUNCnUNCiAgMzk5Ljc1MDAgNjMyLjI1 MDAgbQ0KICAzOTkuMjUwMCA2MzIuNzUwMCBMDQpTDQpVDQp1DQogIDQwMC4wMDAwIDYzMi4w MDAwIG0NCiAgMzk5Ljc1MDAgNjMyLjI1MDAgTA0KUw0KVQ0KdQ0KICA0MDAuMjUwMCA2MzEu NTAwMCBtDQogIDQwMC4wMDAwIDYzMi4wMDAwIEwNClMNClUNCnUNCiAgNDAwLjc1MDAgNjMx LjI1MDAgbQ0KICA0MDAuMjUwMCA2MzEuNTAwMCBMDQpTDQpVDQp1DQogIDQwMS4wMDAwIDYz MC43NTAwIG0NCiAgNDAwLjc1MDAgNjMxLjI1MDAgTA0KUw0KVQ0KdQ0KICA0MDEuMDAwMCA2 MzAuNTAwMCBtDQogIDQwMS4wMDAwIDYzMC43NTAwIEwNClMNClUNCnUNCiAgNDAxLjUwMDAg NjMwLjAwMDAgbQ0KICA0MDEuMDAwMCA2MzAuNTAwMCBMDQpTDQpVDQp1DQogIDQwMS43NTAw IDYyOS41MDAwIG0NCiAgNDAxLjUwMDAgNjMwLjAwMDAgTA0KUw0KVQ0KdQ0KICA0MDEuNzUw MCA2MjkuMjUwMCBtDQogIDQwMS43NTAwIDYyOS41MDAwIEwNClMNClUNCnUNCiAgNDAyLjAw MDAgNjI4Ljc1MDAgbQ0KICA0MDEuNzUwMCA2MjkuMjUwMCBMDQpTDQpVDQp1DQogIDQwMi4w MDAwIDYyOC4yNTAwIG0NCiAgNDAyLjAwMDAgNjI4Ljc1MDAgTA0KUw0KVQ0KdQ0KICA0MDIu MDAwMCA2MjcuNzUwMCBtDQogIDQwMi4wMDAwIDYyOC4yNTAwIEwNClMNClUNCnUNCiAgNDAy LjAwMDAgNjI3LjI1MDAgbQ0KICA0MDIuMDAwMCA2MjcuNzUwMCBMDQpTDQpVDQp1DQogIDQw Mi4yNTAwIDYyNi43NTAwIG0NCiAgNDAyLjAwMDAgNjI3LjI1MDAgTA0KUw0KVQ0KdQ0KICA0 MDIuMjUwMCA2MjYuNTAwMCBtDQogIDQwMi4yNTAwIDYyNi43NTAwIEwNClMNClUNCnUNCiAg NDAyLjAwMDAgNjI2LjAwMDAgbQ0KICA0MDIuMjUwMCA2MjYuNTAwMCBMDQpTDQpVDQp1DQog IDQwMi4wMDAwIDYyNS41MDAwIG0NCiAgNDAyLjAwMDAgNjI2LjAwMDAgTA0KUw0KVQ0KdQ0K ICA0MDIuMDAwMCA2MjUuMDAwMCBtDQogIDQwMi4wMDAwIDYyNS41MDAwIEwNClMNClUNCnUN CiAgNDAyLjAwMDAgNjI0LjUwMDAgbQ0KICA0MDIuMDAwMCA2MjUuMDAwMCBMDQpTDQpVDQp1 DQogIDQwMS43NTAwIDYyNC4wMDAwIG0NCiAgNDAyLjAwMDAgNjI0LjUwMDAgTA0KUw0KVQ0K dQ0KICA0MDEuNTAwMCA2MjMuNTAwMCBtDQogIDQwMS43NTAwIDYyNC4wMDAwIEwNClMNClUN CnUNCiAgNDAxLjI1MDAgNjIzLjAwMDAgbQ0KICA0MDEuNTAwMCA2MjMuNTAwMCBMDQpTDQpV DQp1DQogIDQwMS4yNTAwIDYyMi43NTAwIG0NCiAgNDAxLjI1MDAgNjIzLjAwMDAgTA0KUw0K VQ0KdQ0KICA0MDEuMDAwMCA2MjIuMjUwMCBtDQogIDQwMS4yNTAwIDYyMi43NTAwIEwNClMN ClUNCnUNCiAgNDAwLjc1MDAgNjIxLjc1MDAgbQ0KICA0MDEuMDAwMCA2MjIuMjUwMCBMDQpT DQpVDQp1DQogIDQwMC41MDAwIDYyMS41MDAwIG0NCiAgNDAwLjc1MDAgNjIxLjc1MDAgTA0K Uw0KVQ0KdQ0KICA0MDAuMjUwMCA2MjEuMjUwMCBtDQogIDQwMC41MDAwIDYyMS41MDAwIEwN ClMNClUNCnUNCiAgNDAwLjAwMDAgNjIxLjAwMDAgbQ0KICA0MDAuMjUwMCA2MjEuMjUwMCBM DQpTDQpVDQp1DQogIDM5OS43NTAwIDYyMC41MDAwIG0NCiAgNDAwLjAwMDAgNjIxLjAwMDAg TA0KUw0KVQ0KdQ0KICAzOTkuNTAwMCA2MjAuMjUwMCBtDQogIDM5OS43NTAwIDYyMC41MDAw IEwNClMNClUNCnUNCiAgMzk5LjAwMDAgNjIwLjAwMDAgbQ0KICAzOTkuNTAwMCA2MjAuMjUw MCBMDQpTDQpVDQp1DQogIDM5OC43NTAwIDYxOS43NTAwIG0NCiAgMzk5LjAwMDAgNjIwLjAw MDAgTA0KUw0KVQ0KdQ0KICAzOTguNTAwMCA2MTkuNzUwMCBtDQogIDM5OC43NTAwIDYxOS43 NTAwIEwNClMNClUNCnUNCiAgMzk4LjAwMDAgNjE5LjUwMDAgbQ0KICAzOTguNTAwMCA2MTku NzUwMCBMDQpTDQpVDQp1DQogIDM5Ny43NTAwIDYxOS4yNTAwIG0NCiAgMzk4LjAwMDAgNjE5 LjUwMDAgTA0KUw0KVQ0KdQ0KICAzOTcuNTAwMCA2MTkuMDAwMCBtDQogIDM5Ny43NTAwIDYx OS4yNTAwIEwNClMNClUNCnUNCiAgMzk3LjAwMDAgNjE5LjAwMDAgbQ0KICAzOTcuNTAwMCA2 MTkuMDAwMCBMDQpTDQpVDQp1DQogIDM5Ni43NTAwIDYxOC43NTAwIG0NCiAgMzk3LjAwMDAg NjE5LjAwMDAgTA0KUw0KVQ0KdQ0KICAzOTYuMjUwMCA2MTguNTAwMCBtDQogIDM5Ni43NTAw IDYxOC43NTAwIEwNClMNClUNCnUNCiAgMzk2LjAwMDAgNjE4LjUwMDAgbQ0KICAzOTYuMjUw MCA2MTguNTAwMCBMDQpTDQpVDQp1DQogIDM5NS43NTAwIDYxOC4yNTAwIG0NCiAgMzk2LjAw MDAgNjE4LjUwMDAgTA0KUw0KVQ0KdQ0KICAzOTUuMjUwMCA2MTguMDAwMCBtDQogIDM5NS43 NTAwIDYxOC4yNTAwIEwNClMNClUNCnUNCiAgMzk1LjAwMDAgNjE4LjAwMDAgbQ0KICAzOTUu MjUwMCA2MTguMDAwMCBMDQpTDQpVDQp1DQogIDM5NC43NTAwIDYxNy43NTAwIG0NCiAgMzk1 LjAwMDAgNjE4LjAwMDAgTA0KUw0KVQ0KdQ0KICAzOTQuNTAwMCA2MTcuNTAwMCBtDQogIDM5 NC43NTAwIDYxNy43NTAwIEwNClMNClUNCnUNCiAgMzk0LjAwMDAgNjE3LjUwMDAgbQ0KICAz OTQuNTAwMCA2MTcuNTAwMCBMDQpTDQpVDQp1DQogIDM5My43NTAwIDYxNy4wMDAwIG0NCiAg Mzk0LjAwMDAgNjE3LjUwMDAgTA0KUw0KVQ0KdQ0KICAzOTMuNzUwMCA2MTYuNzUwMCBtDQog IDM5My43NTAwIDYxNy4wMDAwIEwNClMNClUNCnUNCiAgMzkzLjI1MDAgNjE2LjUwMDAgbQ0K ICAzOTMuNzUwMCA2MTYuNzUwMCBMDQpTDQpVDQp1DQogIDM5My4wMDAwIDYxNi4yNTAwIG0N CiAgMzkzLjI1MDAgNjE2LjUwMDAgTA0KUw0KVQ0KdQ0KICAzOTIuNzUwMCA2MTUuNzUwMCBt DQogIDM5My4wMDAwIDYxNi4yNTAwIEwNClMNClUNCnUNCiAgMzkyLjc1MDAgNjE1LjI1MDAg bQ0KICAzOTIuNzUwMCA2MTUuNzUwMCBMDQpTDQpVDQp1DQogIDM5Mi4yNTAwIDYxNC43NTAw IG0NCiAgMzkyLjc1MDAgNjE1LjI1MDAgTA0KUw0KVQ0KdQ0KICAzOTIuMDAwMCA2MTQuMjUw MCBtDQogIDM5Mi4yNTAwIDYxNC43NTAwIEwNClMNClUNCnUNCiAgMzkxLjc1MDAgNjE0LjAw MDAgbQ0KICAzOTIuMDAwMCA2MTQuMjUwMCBMDQpTDQpVDQp1DQogIDM5MS41MDAwIDYxMy41 MDAwIG0NCiAgMzkxLjc1MDAgNjE0LjAwMDAgTA0KUw0KVQ0KdQ0KICAzOTEuMDAwMCA2MTMu MDAwMCBtDQogIDM5MS41MDAwIDYxMy41MDAwIEwNClMNClUNCnUNCiAgMzkwLjc1MDAgNjEy LjUwMDAgbQ0KICAzOTEuMDAwMCA2MTMuMDAwMCBMDQpTDQpVDQp1DQogIDM5MC4yNTAwIDYx Mi4yNTAwIG0NCiAgMzkwLjc1MDAgNjEyLjUwMDAgTA0KUw0KVQ0KdQ0KICAzOTAuMDAwMCA2 MTEuNzUwMCBtDQogIDM5MC4yNTAwIDYxMi4yNTAwIEwNClMNClUNCnUNCiAgMzg5LjUwMDAg NjExLjUwMDAgbQ0KICAzOTAuMDAwMCA2MTEuNzUwMCBMDQpTDQpVDQp1DQogIDM4OS4wMDAw IDYxMS4yNTAwIG0NCiAgMzg5LjUwMDAgNjExLjUwMDAgTA0KUw0KVQ0KdQ0KICAzODguNTAw MCA2MTAuNzUwMCBtDQogIDM4OS4wMDAwIDYxMS4yNTAwIEwNClMNClUNCnUNCiAgMzg4LjAw MDAgNjEwLjUwMDAgbQ0KICAzODguNTAwMCA2MTAuNzUwMCBMDQpTDQpVDQp1DQogIDM4Ny41 MDAwIDYxMC4yNTAwIG0NCiAgMzg4LjAwMDAgNjEwLjUwMDAgTA0KUw0KVQ0KdQ0KICAzODcu MDAwMCA2MTAuMjUwMCBtDQogIDM4Ny41MDAwIDYxMC4yNTAwIEwNClMNClUNCnUNCiAgMzg2 LjUwMDAgNjEwLjAwMDAgbQ0KICAzODcuMDAwMCA2MTAuMjUwMCBMDQpTDQpVDQp1DQogIDM4 Ni4wMDAwIDYwOS43NTAwIG0NCiAgMzg2LjUwMDAgNjEwLjAwMDAgTA0KUw0KVQ0KdQ0KICAz ODUuNTAwMCA2MDkuNzUwMCBtDQogIDM4Ni4wMDAwIDYwOS43NTAwIEwNClMNClUNCnUNCiAg Mzg1LjAwMDAgNjA5Ljc1MDAgbQ0KICAzODUuNTAwMCA2MDkuNzUwMCBMDQpTDQpVDQp1DQog IDM4NC41MDAwIDYwOS41MDAwIG0NCiAgMzg1LjAwMDAgNjA5Ljc1MDAgTA0KUw0KVQ0KdQ0K ICAzODMuNzUwMCA2MDkuNTAwMCBtDQogIDM4NC41MDAwIDYwOS41MDAwIEwNClMNClUNCnUN CiAgMzgzLjUwMDAgNjA5LjUwMDAgbQ0KICAzODMuNzUwMCA2MDkuNTAwMCBMDQpTDQpVDQp1 DQogIDM4My4wMDAwIDYwOS41MDAwIG0NCiAgMzgzLjUwMDAgNjA5LjUwMDAgTA0KUw0KVQ0K dQ0KICAzODIuNTAwMCA2MDkuNTAwMCBtDQogIDM4My4wMDAwIDYwOS41MDAwIEwNClMNClUN CnUNCiAgMzgyLjAwMDAgNjA5LjUwMDAgbQ0KICAzODIuNTAwMCA2MDkuNTAwMCBMDQpTDQpV DQp1DQogIDM4MS43NTAwIDYwOS41MDAwIG0NCiAgMzgyLjAwMDAgNjA5LjUwMDAgTA0KUw0K VQ0KdQ0KICAzODEuNTAwMCA2MDkuNzUwMCBtDQogIDM4MS43NTAwIDYwOS41MDAwIEwNClMN ClUNCnUNCiAgMzgxLjAwMDAgNjA5Ljc1MDAgbQ0KICAzODEuNTAwMCA2MDkuNzUwMCBMDQpT DQpVDQp1DQogIDM4MC41MDAwIDYwOS43NTAwIG0NCiAgMzgxLjAwMDAgNjA5Ljc1MDAgTA0K Uw0KVQ0KdQ0KICAzODAuMjUwMCA2MDkuNzUwMCBtDQogIDM4MC41MDAwIDYwOS43NTAwIEwN ClMNClUNCnUNCiAgMzc5Ljc1MDAgNjEwLjAwMDAgbQ0KICAzODAuMjUwMCA2MDkuNzUwMCBM DQpTDQpVDQp1DQogIDM3OS4yNTAwIDYxMC4wMDAwIG0NCiAgMzc5Ljc1MDAgNjEwLjAwMDAg TA0KUw0KVQ0KdQ0KICAzNzguNzUwMCA2MTAuMjUwMCBtDQogIDM3OS4yNTAwIDYxMC4wMDAw IEwNClMNClUNCnUNCiAgMzc4LjUwMDAgNjEwLjI1MDAgbQ0KICAzNzguNzUwMCA2MTAuMjUw MCBMDQpTDQpVDQp1DQogIDM3OC4wMDAwIDYxMC4yNTAwIG0NCiAgMzc4LjUwMDAgNjEwLjI1 MDAgTA0KUw0KVQ0KdQ0KICAzNzcuNTAwMCA2MTAuNTAwMCBtDQogIDM3OC4wMDAwIDYxMC4y NTAwIEwNClMNClUNCnUNCiAgMzc3LjAwMDAgNjEwLjc1MDAgbQ0KICAzNzcuNTAwMCA2MTAu NTAwMCBMDQpTDQpVDQp1DQogIDM3Ni41MDAwIDYxMC43NTAwIG0NCiAgMzc3LjAwMDAgNjEw Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzNzYuMjUwMCA2MTEuMDAwMCBtDQogIDM3Ni41MDAwIDYx MS4wMDAwIEwNClMNClUNCnUNCiAgMzc1Ljc1MDAgNjExLjI1MDAgbQ0KICAzNzYuMjUwMCA2 MTEuMDAwMCBMDQpTDQpVDQp1DQogIDM3NS4yNTAwIDYxMS4yNTAwIG0NCiAgMzc1Ljc1MDAg NjExLjI1MDAgTA0KUw0KVQ0KdQ0KICAzNzQuNzUwMCA2MTEuNTAwMCBtDQogIDM3NS4yNTAw IDYxMS4yNTAwIEwNClMNClUNCnUNCiAgMzc0LjUwMDAgNjExLjUwMDAgbQ0KICAzNzQuNzUw MCA2MTEuNTAwMCBMDQpTDQpVDQp1DQogIDM3NC4wMDAwIDYxMS43NTAwIG0NCiAgMzc0LjUw MDAgNjExLjUwMDAgTA0KUw0KVQ0KdQ0KICAzNzMuNzUwMCA2MTEuNzUwMCBtDQogIDM3NC4w MDAwIDYxMS43NTAwIEwNClMNClUNCnUNCiAgMzczLjUwMDAgNjExLjUwMDAgbQ0KICAzNzMu NzUwMCA2MTEuNzUwMCBMDQpTDQpVDQp1DQogIDM3My4yNTAwIDYxMS41MDAwIG0NCiAgMzcz LjUwMDAgNjExLjUwMDAgTA0KUw0KVQ0KdQ0KICAzNzMuMDAwMCA2MTEuMjUwMCBtDQogIDM3 My4yNTAwIDYxMS41MDAwIEwNClMNClUNCnUNCiAgMzcyLjc1MDAgNjExLjI1MDAgbQ0KICAz NzMuMDAwMCA2MTEuMjUwMCBMDQpTDQpVDQp1DQogIDM3Mi41MDAwIDYxMS4wMDAwIG0NCiAg MzcyLjc1MDAgNjExLjI1MDAgTA0KUw0KVQ0KdQ0KICAzNzIuMjUwMCA2MTAuNzUwMCBtDQog IDM3Mi41MDAwIDYxMS4wMDAwIEwNClMNClUNCnUNCiAgMzcyLjAwMDAgNjEwLjI1MDAgbQ0K ICAzNzIuMjUwMCA2MTAuNzUwMCBMDQpTDQpVDQp1DQogIDM3MS43NTAwIDYxMC4yNTAwIG0N CiAgMzcyLjAwMDAgNjEwLjI1MDAgTA0KUw0KVQ0KdQ0KICAzNzEuNTAwMCA2MDkuNzUwMCBt DQogIDM3MS43NTAwIDYxMC4yNTAwIEwNClMNClUNCnUNCiAgMzcxLjI1MDAgNjA5LjUwMDAg bQ0KICAzNzEuNTAwMCA2MDkuNzUwMCBMDQpTDQpVDQp1DQogIDM3MS4wMDAwIDYwOS4yNTAw IG0NCiAgMzcxLjI1MDAgNjA5LjUwMDAgTA0KUw0KVQ0KdQ0KICAzNzAuNTAwMCA2MDkuMjUw MCBtDQogIDM3MS4wMDAwIDYwOS4yNTAwIEwNClMNClUNCnUNCiAgMzcwLjI1MDAgNjUzLjI1 MDAgbQ0KICAzNzAuNzUwMCA2NTMuNTAwMCBMDQpTDQpVDQp1DQogIDM2NS4wMDAwIDY1My43 NTAwIG0NCiAgMzY1LjUwMDAgNjUzLjc1MDAgTA0KUw0KVQ0KdQ0KICAzNjUuNTAwMCA2NTMu NzUwMCBtDQogIDM2Ni4wMDAwIDY1My41MDAwIEwNClMNClUNCnUNCiAgMzY2LjAwMDAgNjUz LjUwMDAgbQ0KICAzNjYuNTAwMCA2NTMuMjUwMCBMDQpTDQpVDQp1DQogIDM2Ni41MDAwIDY1 My4yNTAwIG0NCiAgMzY3LjAwMDAgNjUzLjI1MDAgTA0KUw0KVQ0KdQ0KICAzNjcuMDAwMCA2 NTMuMjUwMCBtDQogIDM2Ny4yNTAwIDY1My4wMDAwIEwNClMNClUNCnUNCiAgMzY3LjI1MDAg NjUzLjAwMDAgbQ0KICAzNjcuNzUwMCA2NTMuMDAwMCBMDQpTDQpVDQp1DQogIDM2Ny43NTAw IDY1My4wMDAwIG0NCiAgMzY4LjI1MDAgNjUzLjAwMDAgTA0KUw0KVQ0KdQ0KICAzNjguMjUw MCA2NTMuMDAwMCBtDQogIDM2OC43NTAwIDY1Mi43NTAwIEwNClMNClUNCnUNCiAgMzY4Ljc1 MDAgNjUyLjc1MDAgbQ0KICAzNjkuMjUwMCA2NTMuMDAwMCBMDQpTDQpVDQp1DQogIDM2OS4y NTAwIDY1Mi43NTAwIG0NCiAgMzY5Ljc1MDAgNjUzLjAwMDAgTA0KUw0KVQ0KdQ0KICAzNjku NzUwMCA2NTMuMDAwMCBtDQogIDM3MC4yNTAwIDY1My4yNTAwIEwNClMNClUNCnUNCiAgMzU2 Ljc1MDAgNjUxLjUwMDAgbQ0KICAzNTcuMjUwMCA2NTEuNzUwMCBMDQpTDQpVDQp1DQogIDM1 Ny4yNTAwIDY1MS43NTAwIG0NCiAgMzU3LjUwMDAgNjUyLjAwMDAgTA0KUw0KVQ0KdQ0KICAz NTcuNTAwMCA2NTIuMDAwMCBtDQogIDM1OC4wMDAwIDY1Mi41MDAwIEwNClMNClUNCnUNCiAg MzU4LjAwMDAgNjUyLjUwMDAgbQ0KICAzNTguNzUwMCA2NTMuMDAwMCBMDQpTDQpVDQp1DQog IDM1OC43NTAwIDY1My4wMDAwIG0NCiAgMzU5LjI1MDAgNjUzLjI1MDAgTA0KUw0KVQ0KdQ0K ICAzNTkuMjUwMCA2NTMuMjUwMCBtDQogIDM1OS43NTAwIDY1My41MDAwIEwNClMNClUNCnUN CiAgMzU5Ljc1MDAgNjUzLjUwMDAgbQ0KICAzNjAuMjUwMCA2NTMuNzUwMCBMDQpTDQpVDQp1 DQogIDM2MC4yNTAwIDY1My43NTAwIG0NCiAgMzYxLjAwMDAgNjUzLjc1MDAgTA0KUw0KVQ0K dQ0KICAzNjEuMDAwMCA2NTMuNzUwMCBtDQogIDM2MS41MDAwIDY1NC4wMDAwIEwNClMNClUN CnUNCiAgMzYxLjUwMDAgNjU0LjAwMDAgbQ0KICAzNjIuMjUwMCA2NTQuMDAwMCBMDQpTDQpV DQp1DQogIDM2Mi4yNTAwIDY1NC4wMDAwIG0NCiAgMzYyLjc1MDAgNjU0LjAwMDAgTA0KUw0K VQ0KdQ0KICAzNjIuNzUwMCA2NTQuMDAwMCBtDQogIDM2My4yNTAwIDY1NC4wMDAwIEwNClMN ClUNCnUNCiAgMzYzLjI1MDAgNjU0LjAwMDAgbQ0KICAzNjMuNzUwMCA2NTQuMDAwMCBMDQpT DQpVDQp1DQogIDM2My43NTAwIDY1NC4wMDAwIG0NCiAgMzY0LjUwMDAgNjU0LjAwMDAgTA0K Uw0KVQ0KdQ0KICAzNjQuNTAwMCA2NTQuMDAwMCBtDQogIDM2NS4wMDAwIDY1My43NTAwIEwN ClMNClUNCnUNCiAgMzcwLjc1MDAgNjUzLjUwMDAgbQ0KICAzNzEuMjUwMCA2NTMuNzUwMCBM DQpTDQpVDQp1DQogIDM3MS4yNTAwIDY1My43NTAwIG0NCiAgMzcyLjAwMDAgNjUzLjc1MDAg TA0KUw0KVQ0KdQ0KICAzNzIuMDAwMCA2NTMuNzUwMCBtDQogIDM3Mi41MDAwIDY1NC4wMDAw IEwNClMNClUNCnUNCiAgMzcyLjUwMDAgNjU0LjAwMDAgbQ0KICAzNzMuMjUwMCA2NTQuMjUw MCBMDQpTDQpVDQp1DQogIDM3My4yNTAwIDY1NC4yNTAwIG0NCiAgMzczLjc1MDAgNjU0LjUw MDAgTA0KUw0KVQ0KdQ0KICAzNzMuNzUwMCA2NTQuNTAwMCBtDQogIDM3NC41MDAwIDY1NC43 NTAwIEwNClMNClUNCnUNCiAgMzc0LjUwMDAgNjU0Ljc1MDAgbQ0KICAzNzUuNTAwMCA2NTQu NzUwMCBMDQpTDQpVDQp1DQogIDM3NS41MDAwIDY1NC43NTAwIG0NCiAgMzc2LjAwMDAgNjU1 LjAwMDAgTA0KUw0KVQ0KdQ0KICAzNzYuMDAwMCA2NTUuMDAwMCBtDQogIDM3Ni43NTAwIDY1 NS4yNTAwIEwNClMNClUNCnUNCiAgMzc2Ljc1MDAgNjU1LjI1MDAgbQ0KICAzNzcuNTAwMCA2 NTUuMjUwMCBMDQpTDQpVDQp1DQogIDM3Ny41MDAwIDY1NS4yNTAwIG0NCiAgMzc4LjI1MDAg NjU1LjI1MDAgTA0KUw0KVQ0KdQ0KICAzNzguMjUwMCA2NTUuMjUwMCBtDQogIDM3OC43NTAw IDY1NS4yNTAwIEwNClMNClUNCnUNCiAgMzc4Ljc1MDAgNjU1LjI1MDAgbQ0KICAzNzkuNTAw MCA2NTUuMDAwMCBMDQpTDQpVDQp1DQogIDM3OS41MDAwIDY1NS4wMDAwIG0NCiAgMzgwLjAw MDAgNjU0Ljc1MDAgTA0KUw0KVQ0KdQ0KICAzODAuMDAwMCA2NTQuNzUwMCBtDQogIDM4MC43 NTAwIDY1NC43NTAwIEwNClMNClUNCnUNCiAgMzgwLjc1MDAgNjU0Ljc1MDAgbQ0KICAzODEu MjUwMCA2NTQuNTAwMCBMDQpTDQpVDQp1DQogIDM4MS4yNTAwIDY1NC41MDAwIG0NCiAgMzgx Ljc1MDAgNjU0LjI1MDAgTA0KUw0KVQ0KdQ0KICAzODEuNzUwMCA2NTQuMjUwMCBtDQogIDM4 Mi4wMDAwIDY1NC4wMDAwIEwNClMNClUNCnUNCiAgMzgyLjAwMDAgNjU0LjAwMDAgbQ0KICAz ODIuNTAwMCA2NTMuNzUwMCBMDQpTDQpVDQp1DQogIDM4Mi41MDAwIDY1My43NTAwIG0NCiAg MzgyLjc1MDAgNjUzLjI1MDAgTA0KUw0KVQ0KdQ0KICAzODIuNzUwMCA2NTMuMjUwMCBtDQog IDM4My4yNTAwIDY1My4wMDAwIEwNClMNClUNCnUNCiAgMzgzLjI1MDAgNjUzLjAwMDAgbQ0K ICAzODMuNTAwMCA2NTIuNzUwMCBMDQpTDQpVDQp1DQogIDM4My41MDAwIDY1Mi41MDAwIG0N CiAgMzgzLjc1MDAgNjUyLjI1MDAgTA0KUw0KVQ0KdQ0KICAzODMuNzUwMCA2NTIuMjUwMCBt DQogIDM4NC4yNTAwIDY1MS43NTAwIEwNClMNClUNCnUNCiAgMzg0LjI1MDAgNjUxLjc1MDAg bQ0KICAzODQuNTAwMCA2NTEuNTAwMCBMDQpTDQpVDQp1DQoxLjUwMDAgdw0KICA0NzYuMDAw MCA2MDAuNzUwMCBtDQogIDQ3Ni4wMDAwIDYwNC4yNTAwIEwNCiAgNDg3LjUwMDAgNjA0LjI1 MDAgTA0KICA0ODcuNTAwMCA2MDAuNzUwMCBMDQogIDQ4Ny41MDAwIDYwMC43NTAwIEwNCiAg NDg3LjUwMDAgNjAwLjc1MDAgTA0KUw0KVQ0KdQ0KMSBqDQogIDQ3OC43NTAwIDYwMS4yNTAw IG0NCiAgNDg0LjUwMDAgNjAxLjI1MDAgTA0KUw0KVQ0KdQ0KICA0ODEuNTAwMCA2MDEuMjUw MCBtDQogIDQ4MS41MDAwIDU5MC4wMDAwIEwNClMNClUNCiAgMC4wMDAgMC4wMDAgMC4wMDAg MC4wMDAgaw0KMC4wMDAwIHcNCiAgMC4wMDAgMC4wMDAgMC4wMDAgMC4wMDAgaw0KICAwLjAw MCAwLjAwMCAwLjAwMCAwLjAwMCBrDQoqdQ0KICA0ODkuNzUwMCA1NzYuNzUwMCBtDQogIDQ5 MS4wMDAwIDU3Ni43NTAwICA0OTIuMDAwMCA1NzcuNzUwMCAgNDkyLjAwMDAgNTc5LjAwMDAg Qw0KICA0OTIuMDAwMCA1ODguMjUwMCBMDQogIDQ5Mi4wMDAwIDU4OS43NTAwICA0OTEuMDAw MCA1OTAuNzUwMCAgNDg5Ljc1MDAgNTkwLjc1MDAgQw0KICA0NzIuNTAwMCA1OTAuNzUwMCBM DQogIDQ3MS4yNTAwIDU5MC43NTAwICA0NzAuMjUwMCA1ODkuNTAwMCAgNDcwLjI1MDAgNTg4 LjI1MDAgQw0KICA0NzAuMjUwMCA1NzkuMDAwMCBMDQogIDQ3MC4yNTAwIDU3Ny43NTAwICA0 NzEuMjUwMCA1NzYuNzUwMCAgNDcyLjUwMDAgNTc2Ljc1MDAgQw0KICA0ODkuNzUwMCA1NzYu NzUwMCBMDQpCDQoqVQ0KdQ0KMS41MDAwIHcNCjAgag0KICA0NDIuMDAwMCA2MjkuNzUwMCBt DQogIDU0MS4wMDAwIDYyOS43NTAwIEwNCiAgNTQxLjAwMDAgNjYwLjc1MDAgTA0KUw0KVQ0K dQ0KICA0ODEuNTAwMCA2MDQuMjUwMCBtDQogIDQ4MS41MDAwIDYyOS43NTAwIEwNClMNClUN CnUNCiAgNTIxLjI1MDAgNjA0LjI1MDAgbQ0KICA1MjEuMjUwMCA2MjkuNzUwMCBMDQpTDQpV DQogIDAuMDAwIDAuMDAwIDAuMDAwIDAuMDAwIGsNCjAuMDAwMCB3DQogIDAuMDAwIDAuMDAw IDAuMDAwIDAuMDAwIGsNCiAgMC4wMDAgMC4wMDAgMC4wMDAgMC4wMDAgaw0KKnUNCiAgNTI5 LjUwMDAgNTkwLjI1MDAgbQ0KICA1MzAuNzUwMCA1OTAuMjUwMCAgNTMxLjc1MDAgNTkxLjI1 MDAgIDUzMS41MDAwIDU5Mi41MDAwIEMNCiAgNTMxLjUwMDAgNjAxLjc1MDAgTA0KICA1MzEu NTAwMCA2MDMuMDAwMCAgNTMwLjUwMDAgNjA0LjI1MDAgIDUyOS41MDAwIDYwNC4wMDAwIEMN CiAgNTEyLjAwMDAgNjA0LjAwMDAgTA0KICA1MTEuMDAwMCA2MDQuMDAwMCAgNTEwLjAwMDAg NjAzLjAwMDAgIDUxMC4wMDAwIDYwMS43NTAwIEMNCiAgNTEwLjAwMDAgNTkyLjUwMDAgTA0K ICA1MTAuMDAwMCA1OTEuMjUwMCAgNTExLjAwMDAgNTkwLjI1MDAgIDUxMi4wMDAwIDU5MC4y NTAwIEMNCiAgNTI5LjUwMDAgNTkwLjI1MDAgTA0KQg0KKlUNCiAgMC4wMDAgMC4wMDAgMC4w MDAgMC4wMDAgaw0KICAwLjAwMCAwLjAwMCAwLjAwMCAwLjAwMCBrDQogIDAuMDAwIDAuMDAw IDAuMDAwIDAuMDAwIGsNCip1DQogIDU0OS4yNTAwIDY2MS4wMDAwIG0NCiAgNTUwLjUwMDAg NjYxLjAwMDAgIDU1MS41MDAwIDY2Mi4wMDAwICA1NTEuNTAwMCA2NjMuMjUwMCBDDQogIDU1 MS41MDAwIDY3Mi43NTAwIEwNCiAgNTUxLjUwMDAgNjc0LjAwMDAgIDU1MC41MDAwIDY3NS4w MDAwICA1NDkuMjUwMCA2NzUuMDAwMCBDDQogIDUzMi4wMDAwIDY3NS4wMDAwIEwNCiAgNTMw Ljc1MDAgNjc1LjAwMDAgIDUyOS43NTAwIDY3NC4wMDAwICA1MjkuNzUwMCA2NzIuNzUwMCBD DQogIDUyOS43NTAwIDY2My4yNTAwIEwNCiAgNTI5Ljc1MDAgNjYyLjAwMDAgIDUzMC43NTAw IDY2MS4wMDAwICA1MzIuMDAwMCA2NjEuMDAwMCBDDQogIDU0OS4yNTAwIDY2MS4wMDAwIEwN CkINCipVDQp1DQoxLjUwMDAgdw0KICA1MDEuNTAwMCA2MjkuNzUwMCBtDQogIDUwMS41MDAw IDY2MC43NTAwIEwNClMNClUNCnUNCiAgNDYxLjc1MDAgNjI5Ljc1MDAgbQ0KICA0NjEuNzUw MCA2NjAuNzUwMCBMDQpTDQpVDQogIDAuMDAwIDAuMDAwIDAuMDAwIDAuMDAwIGsNCjAuMDAw MCB3DQogIDAuMDAwIDAuMDAwIDAuMDAwIDAuMDAwIGsNCiAgMC4wMDAgMC4wMDAgMC4wMDAg MC4wMDAgaw0KKnUNCiAgNDcwLjAwMDAgNjYxLjAwMDAgbQ0KICA0NzEuMDAwMCA2NjEuMDAw MCAgNDcyLjAwMDAgNjYyLjAwMDAgIDQ3Mi4wMDAwIDY2My4yNTAwIEMNCiAgNDcyLjAwMDAg NjcyLjc1MDAgTA0KICA0NzIuMDAwMCA2NzQuMDAwMCAgNDcxLjAwMDAgNjc1LjAwMDAgIDQ3 MC4wMDAwIDY3NS4wMDAwIEMNCiAgNDUyLjUwMDAgNjc1LjAwMDAgTA0KICA0NTEuNTAwMCA2 NzUuMDAwMCAgNDUwLjUwMDAgNjc0LjAwMDAgIDQ1MC41MDAwIDY3Mi43NTAwIEMNCiAgNDUw LjUwMDAgNjYzLjI1MDAgTA0KICA0NTAuNTAwMCA2NjIuMDAwMCAgNDUxLjUwMDAgNjYxLjAw MDAgIDQ1Mi41MDAwIDY2MS4wMDAwIEMNCiAgNDcwLjAwMDAgNjYxLjAwMDAgTA0KQg0KKlUN CiAgMC4wMDAgMC4wMDAgMC4wMDAgMC4wMDAgaw0KICAwLjAwMCAwLjAwMCAwLjAwMCAwLjAw MCBrDQogIDAuMDAwIDAuMDAwIDAuMDAwIDAuMDAwIGsNCip1DQogIDUwOS43NTAwIDY2MS4w MDAwIG0NCiAgNTEwLjc1MDAgNjYxLjAwMDAgIDUxMS43NTAwIDY2Mi4wMDAwICA1MTEuNzUw MCA2NjMuMjUwMCBDDQogIDUxMS43NTAwIDY3Mi43NTAwIEwNCiAgNTExLjc1MDAgNjc0LjAw MDAgIDUxMC43NTAwIDY3NS4wMDAwICA1MDkuNzUwMCA2NzUuMDAwMCBDDQogIDQ5Mi4yNTAw IDY3NS4wMDAwIEwNCiAgNDkxLjAwMDAgNjc1LjAwMDAgIDQ5MC4wMDAwIDY3NC4wMDAwICA0 OTAuMDAwMCA2NzIuNzUwMCBDDQogIDQ5MC4wMDAwIDY2My4yNTAwIEwNCiAgNDkwLjAwMDAg NjYyLjAwMDAgIDQ5MS4wMDAwIDY2MS4wMDAwICA0OTIuMjUwMCA2NjEuMDAwMCBDDQogIDUw OS43NTAwIDY2MS4wMDAwIEwNCkINCipVDQp1DQogIDAuMDAwIDAuMDAwIDAuMDAwIDEuMDAw IGsNCiAgNDAzLjAwMDAgNjI5LjUwMDAgbQ0KICA0MDMuMjUwMCA2MzIuMjUwMCBMDQogIDQw My4yNTAwIDYzMi4yNTAwIEwNCiAgNDAzLjUwMDAgNjM0LjAwMDAgTA0KICA0MDMuNTAwMCA2 MzQuMDAwMCBMDQogIDQwNC4wMDAwIDYzNS43NTAwIEwNCiAgNDA0LjUwMDAgNjM3LjUwMDAg TA0KICA0MDQuNTAwMCA2MzcuNTAwMCBMDQogIDQwNS4yNTAwIDYzOS4yNTAwIEwNCiAgNDA1 LjI1MDAgNjM5LjAwMDAgTA0KICA0MDYuMjUwMCA2NDAuNTAwMCBMDQogIDQwNy4yNTAwIDY0 Mi4wMDAwIEwNCiAgNDA3LjI1MDAgNjQyLjAwMDAgTA0KICA0MDguNTAwMCA2NDMuMjUwMCBM DQogIDQwOS43NTAwIDY0NC41MDAwIEwNCiAgNDA5Ljc1MDAgNjQ0LjUwMDAgTA0KICA0MTEu MDAwMCA2NDUuNTAwMCBMDQogIDQxMS4wMDAwIDY0NS41MDAwIEwNCiAgNDE0LjI1MDAgNjQ3 LjI1MDAgTA0KICA0MTQuMjUwMCA2NDcuMjUwMCBMDQogIDQxNS43NTAwIDY0Ny43NTAwIEwN CiAgNDE3Ljc1MDAgNjQ4LjI1MDAgTA0KICA0MTcuNzUwMCA2NDguMjUwMCBMDQogIDQxOS41 MDAwIDY0OC41MDAwIEwNCiAgNDE5LjUwMDAgNjQ4LjUwMDAgTA0KICA0MjEuMjUwMCA2NDgu NzUwMCBMDQogIDQyMy4yNTAwIDY0OC41MDAwIEwNCiAgNDIzLjI1MDAgNjQ4LjUwMDAgTA0K ICA0MjUuMDAwMCA2NDguMjUwMCBMDQogIDQyNS4wMDAwIDY0OC4yNTAwIEwNCiAgNDI2Ljc1 MDAgNjQ3Ljc1MDAgTA0KICA0MjguNTAwMCA2NDcuMjUwMCBMDQogIDQyOC41MDAwIDY0Ny4y NTAwIEwNCiAgNDMwLjAwMDAgNjQ2LjUwMDAgTA0KICA0MzAuMDAwMCA2NDYuNTAwMCBMDQog IDQzMS41MDAwIDY0NS41MDAwIEwNCiAgNDMzLjAwMDAgNjQ0LjUwMDAgTA0KICA0MzMuMDAw MCA2NDQuNTAwMCBMDQogIDQzNC4yNTAwIDY0My4yNTAwIEwNCiAgNDM1LjUwMDAgNjQyLjAw MDAgTA0KICA0MzUuMjUwMCA2NDIuMDAwMCBMDQogIDQzNi41MDAwIDY0MC41MDAwIEwNCiAg NDM3LjI1MDAgNjM5LjAwMDAgTA0KICA0MzcuMjUwMCA2MzkuMjUwMCBMDQogIDQzOC4yNTAw IDYzNy41MDAwIEwNCiAgNDM4LjI1MDAgNjM3LjUwMDAgTA0KICA0MzguNzUwMCA2MzUuNzUw MCBMDQogIDQzOS4yNTAwIDYzNC4wMDAwIEwNCiAgNDM5LjI1MDAgNjM0LjAwMDAgTA0KICA0 MzkuNTAwMCA2MzIuMjUwMCBMDQogIDQzOS41MDAwIDYzMi4yNTAwIEwNCiAgNDM5LjUwMDAg NjMwLjUwMDAgTA0KICA0MzkuNTAwMCA2MjguNTAwMCBMDQogIDQzOS41MDAwIDYyOC43NTAw IEwNCiAgNDM5LjI1MDAgNjI2Ljc1MDAgTA0KICA0MzkuMjUwMCA2MjYuNzUwMCBMDQogIDQz OC43NTAwIDYyNS4wMDAwIEwNCiAgNDM4LjI1MDAgNjIzLjI1MDAgTA0KICA0MzguMjUwMCA2 MjMuNTAwMCBMDQogIDQzNy4yNTAwIDYyMS43NTAwIEwNCiAgNDM3LjI1MDAgNjIxLjc1MDAg TA0KICA0MzYuNTAwMCA2MjAuMjUwMCBMDQogIDQzNS4yNTAwIDYxOS4wMDAwIEwNCiAgNDM1 LjUwMDAgNjE5LjAwMDAgTA0KICA0MzQuMjUwMCA2MTcuNTAwMCBMDQogIDQzMy4wMDAwIDYx Ni41MDAwIEwNCiAgNDMzLjAwMDAgNjE2LjUwMDAgTA0KICA0MzEuNTAwMCA2MTUuNTAwMCBM DQogIDQyOC41MDAwIDYxMy43NTAwIEwNCiAgNDI4LjUwMDAgNjEzLjc1MDAgTA0KICA0MjYu NzUwMCA2MTMuMjUwMCBMDQogIDQyNS4wMDAwIDYxMi43NTAwIEwNCiAgNDI1LjAwMDAgNjEy Ljc1MDAgTA0KICA0MjMuMjUwMCA2MTIuNTAwMCBMDQogIDQyMy4yNTAwIDYxMi41MDAwIEwN CiAgNDIxLjI1MDAgNjEyLjI1MDAgTA0KICA0MTkuNTAwMCA2MTIuNTAwMCBMDQogIDQxOS41 MDAwIDYxMi41MDAwIEwNCiAgNDE3Ljc1MDAgNjEyLjc1MDAgTA0KICA0MTcuNzUwMCA2MTIu NzUwMCBMDQogIDQxNS43NTAwIDYxMy4yNTAwIEwNCiAgNDE0LjI1MDAgNjEzLjc1MDAgTA0K ICA0MTQuMjUwMCA2MTMuNzUwMCBMDQogIDQxMS4wMDAwIDYxNS41MDAwIEwNCiAgNDExLjAw MDAgNjE1LjUwMDAgTA0KICA0MDkuNzUwMCA2MTYuNTAwMCBMDQogIDQwOS43NTAwIDYxNi41 MDAwIEwNCiAgNDA4LjUwMDAgNjE3LjUwMDAgTA0KICA0MDcuMjUwMCA2MTkuMDAwMCBMDQog IDQwNy4yNTAwIDYxOS4wMDAwIEwNCiAgNDA2LjI1MDAgNjIwLjI1MDAgTA0KICA0MDUuMjUw MCA2MjEuNzUwMCBMDQogIDQwNS4yNTAwIDYyMS43NTAwIEwNCiAgNDA0LjUwMDAgNjIzLjUw MDAgTA0KICA0MDQuNTAwMCA2MjMuMjUwMCBMDQogIDQwNC4wMDAwIDYyNS4wMDAwIEwNCiAg NDAzLjUwMDAgNjI2Ljc1MDAgTA0KICA0MDMuNTAwMCA2MjYuNzUwMCBMDQogIDQwMy4wMDAw IDYzMC43NTAwIEwNCiAgNDAzLjAwMDAgNjMwLjc1MDAgTA0KICA0MDIuMjUwMCA2MzAuMjUw MCBMDQogIDQwMy4wMDAwIDYyOS41MDAwIEwNCiAgNDAzLjAwMDAgNjMwLjc1MDAgTA0KICA0 MDMuMDAwMCA2MzAuNzUwMCBMDQogIDQwMi4yNTAwIDYzMC4yNTAwIEwNCiAgNDAyLjI1MDAg NjMwLjI1MDAgTA0KICA0MDIuMjUwMCA2MzAuNTAwMCBMDQogIDQwMi4yNTAwIDYyOC41MDAw IEwNCiAgNDAyLjUwMDAgNjI2LjUwMDAgTA0KICA0MDMuMDAwMCA2MjQuNzUwMCBMDQogIDQw My43NTAwIDYyMy4wMDAwIEwNCiAgNDA0LjUwMDAgNjIxLjI1MDAgTA0KICA0MDYuNTAwMCA2 MTguMjUwMCBMDQogIDQwNy43NTAwIDYxNy4wMDAwIEwNCiAgNDA5LjI1MDAgNjE1Ljc1MDAg TA0KICA0MTAuNzUwMCA2MTQuNzUwMCBMDQogIDQxNC4wMDAwIDYxMi43NTAwIEwNCiAgNDE1 Ljc1MDAgNjEyLjI1MDAgTA0KICA0MTcuNTAwMCA2MTEuNzUwMCBMDQogIDQyMS4yNTAwIDYx MS41MDAwIEwNCiAgNDI1LjI1MDAgNjExLjc1MDAgTA0KICA0MjcuMDAwMCA2MTIuMjUwMCBM DQogIDQyOC43NTAwIDYxMy4wMDAwIEwNCiAgNDMwLjUwMDAgNjEzLjc1MDAgTA0KICA0MzIu MDAwMCA2MTQuNzUwMCBMDQogIDQzMy41MDAwIDYxNS43NTAwIEwNCiAgNDM2LjI1MDAgNjE4 LjI1MDAgTA0KICA0MzcuMjUwMCA2MTkuNzUwMCBMDQogIDQzOC4yNTAwIDYyMS41MDAwIEwN CiAgNDM5LjAwMDAgNjIzLjAwMDAgTA0KICA0MzkuNzUwMCA2MjQuNzUwMCBMDQogIDQ0MC4w MDAwIDYyNi43NTAwIEwNCiAgNDQwLjI1MDAgNjI4LjUwMDAgTA0KICA0NDAuNTAwMCA2MzAu NTAwMCBMDQogIDQ0MC4yNTAwIDYzMi41MDAwIEwNCiAgNDQwLjAwMDAgNjM0LjI1MDAgTA0K ICA0MzkuNzUwMCA2MzYuMDAwMCBMDQogIDQzOS4wMDAwIDYzNy43NTAwIEwNCiAgNDM4LjI1 MDAgNjM5LjUwMDAgTA0KICA0MzcuMjUwMCA2NDEuMDAwMCBMDQogIDQzNi4wMDAwIDY0Mi41 MDAwIEwNCiAgNDM0Ljc1MDAgNjQ0LjAwMDAgTA0KICA0MzMuNTAwMCA2NDUuMjUwMCBMDQog IDQzMi4wMDAwIDY0Ni4yNTAwIEwNCiAgNDMwLjUwMDAgNjQ3LjI1MDAgTA0KICA0MjguNzUw MCA2NDguMDAwMCBMDQogIDQyNy4wMDAwIDY0OC43NTAwIEwNCiAgNDI1LjI1MDAgNjQ5LjI1 MDAgTA0KICA0MjMuMjUwMCA2NDkuMjUwMCBMDQogIDQyMS4yNTAwIDY0OS41MDAwIEwNCiAg NDE3LjUwMDAgNjQ5LjI1MDAgTA0KICA0MTUuNzUwMCA2NDguNzUwMCBMDQogIDQxMy43NTAw IDY0OC4wMDAwIEwNCiAgNDEwLjUwMDAgNjQ2LjI1MDAgTA0KICA0MDkuMjUwMCA2NDUuMjUw MCBMDQogIDQwNy43NTAwIDY0NC4wMDAwIEwNCiAgNDA2LjUwMDAgNjQyLjUwMDAgTA0KICA0 MDQuNTAwMCA2MzkuNTAwMCBMDQogIDQwMy4wMDAwIDYzNi4wMDAwIEwNCiAgNDAyLjUwMDAg NjM0LjI1MDAgTA0KICA0MDIuMjUwMCA2MzIuMjUwMCBMDQogIDQwMi4yNTAwIDYzMC41MDAw IEwNCiAgNDAzLjAwMDAgNjMwLjc1MDAgTA0KICA0MDMuMDAwMCA2MjkuNTAwMCBMDQpGDQpV DQp1DQogIDAuMDAwIDAuMDAwIDAuMDAwIDEuMDAwIGsNCiAgNDE3LjI1MDAgNjIwLjUwMDAg bQ0KICA0MTcuMjUwMCA2MjguNTAwMCBMDQogIDQxNi43NTAwIDYyOC4wMDAwIEwNCiAgNDE3 LjI1MDAgNjI4LjAwMDAgTA0KICA0MTcuNTAwMCA2MjkuNzUwMCBMDQogIDQxNy41MDAwIDYy OS43NTAwIEwNCiAgNDE3Ljc1MDAgNjMxLjAwMDAgTA0KICA0MTcuNzUwMCA2MzEuMDAwMCBM DQogIDQxOC4yNTAwIDYzMi4yNTAwIEwNCiAgNDE4LjI1MDAgNjMyLjAwMDAgTA0KICA0MTku MDAwMCA2MzMuMDAwMCBMDQogIDQxOS4wMDAwIDYzMy4wMDAwIEwNCiAgNDIwLjAwMDAgNjMz Ljc1MDAgTA0KICA0MjAuMDAwMCA2MzMuNzUwMCBMDQogIDQyMS4wMDAwIDYzNC4yNTAwIEwN CiAgNDIxLjAwMDAgNjM0LjI1MDAgTA0KICA0MjIuMjUwMCA2MzQuNzUwMCBMDQogIDQyMi4y NTAwIDYzNC43NTAwIEwNCiAgNDIzLjUwMDAgNjM0Ljc1MDAgTA0KICA0MjMuNTAwMCA2MzUu NzUwMCBMDQogIDQyMy41MDAwIDYzNS43NTAwIEwNCiAgNDIzLjUwMDAgNjM0Ljc1MDAgTA0K ICA0MzEuNzUwMCA2MzQuNzUwMCBMDQogIDQzMS43NTAwIDYzNS43NTAwIEwNCiAgNDIzLjUw MDAgNjM1Ljc1MDAgTA0KICA0MjMuNTAwMCA2MzQuNzUwMCBMDQogIDQyMy41MDAwIDYzNC43 NTAwIEwNCiAgNDIzLjUwMDAgNjM1Ljc1MDAgTA0KICA0MjIuMDAwMCA2MzUuNTAwMCBMDQog IDQyMC43NTAwIDYzNS4yNTAwIEwNCiAgNDE5LjUwMDAgNjM0LjUwMDAgTA0KICA0MTguNTAw MCA2MzMuNzUwMCBMDQogIDQxNy41MDAwIDYzMi41MDAwIEwNCiAgNDE3LjAwMDAgNjMxLjUw MDAgTA0KICA0MTYuNTAwMCA2MzAuMDAwMCBMDQogIDQxNi41MDAwIDYyOC43NTAwIEwNCiAg NDE2Ljc1MDAgNjI5LjAwMDAgTA0KICA0MTYuNTAwMCA2MjkuMDAwMCBMDQogIDQxNi4yNTAw IDYyMC41MDAwIEwNCiAgNDE3LjI1MDAgNjIwLjUwMDAgTA0KRg0KVQ0KdQ0KICAwLjAwMCAw LjAwMCAwLjAwMCAxLjAwMCBrDQogIDQyNi4wMDAwIDY0MC41MDAwIG0NCiAgNDI2LjAwMDAg NjMxLjUwMDAgTA0KICA0MjYuNTAwMCA2MzEuNTAwMCBMDQogIDQyNi4wMDAwIDYzMi4wMDAw IEwNCiAgNDI1Ljc1MDAgNjMwLjc1MDAgTA0KICA0MjUuNzUwMCA2MzAuNzUwMCBMDQogIDQy NS41MDAwIDYyOS41MDAwIEwNCiAgNDI1LjUwMDAgNjI5LjUwMDAgTA0KICA0MjUuMDAwMCA2 MjguMjUwMCBMDQogIDQyNS4wMDAwIDYyOC41MDAwIEwNCiAgNDI0LjAwMDAgNjI3LjUwMDAg TA0KICA0MjQuMjUwMCA2MjcuNTAwMCBMDQogIDQyMy4yNTAwIDYyNi41MDAwIEwNCiAgNDIz LjI1MDAgNjI2Ljc1MDAgTA0KICA0MjIuMDAwMCA2MjYuMDAwMCBMDQogIDQyMi4wMDAwIDYy Ni4yNTAwIEwNCiAgNDIwLjc1MDAgNjI1Ljc1MDAgTA0KICA0MjAuNzUwMCA2MjUuNzUwMCBM DQogIDQxOS41MDAwIDYyNS41MDAwIEwNCiAgNDE5LjUwMDAgNjI1LjUwMDAgTA0KICA0MTEu MDAwMCA2MjUuNTAwMCBMDQogIDQxMS4wMDAwIDYyNC41MDAwIEwNCiAgNDE5LjUwMDAgNjI0 LjUwMDAgTA0KICA0MjEuMDAwMCA2MjQuNzUwMCBMDQogIDQyMi41MDAwIDYyNS4yNTAwIEwN CiAgNDIzLjc1MDAgNjI1Ljc1MDAgTA0KICA0MjQuNzUwMCA2MjYuNzUwMCBMDQogIDQyNS43 NTAwIDYyNy43NTAwIEwNCiAgNDI2LjI1MDAgNjI5LjAwMDAgTA0KICA0MjYuNzUwMCA2MzAu NTAwMCBMDQogIDQyNy4wMDAwIDYzMi41MDAwIEwNCiAgNDI2LjUwMDAgNjMyLjUwMDAgTA0K ICA0MjcuMDAwMCA2MzIuMDAwMCBMDQogIDQyNy4wMDAwIDY0MC41MDAwIEwNCiAgNDI2LjAw MDAgNjQwLjUwMDAgTA0KRg0KVQ0KdQ0KICAwLjAwMCAwLjAwMCAwLjAwMCAxLjAwMCBrDQog IDQyMy41MDAwIDY0MS4wMDAwIG0NCiAgNDI1Ljc1MDAgNjQ1LjUwMDAgTA0KICA0MjUuNzUw MCA2NDUuNTAwMCBMDQogIDQyOC4yNTAwIDY0MS4wMDAwIEwNCiAgNDI4LjI1MDAgNjQxLjAw MDAgTA0KICA0MjMuNTAwMCA2NDEuMDAwMCBMDQogIDQyMy41MDAwIDY0MS4wMDAwIEwNCiAg NDIzLjUwMDAgNjQxLjAwMDAgTA0KQg0KVQ0KdQ0KICAwLjAwMCAwLjAwMCAwLjAwMCAxLjAw MCBrDQogIDQzMS41MDAwIDYzNy43NTAwIG0NCiAgNDM2LjAwMDAgNjM1LjI1MDAgTA0KICA0 MzYuMDAwMCA2MzUuMjUwMCBMDQogIDQzMS41MDAwIDYzMi43NTAwIEwNCiAgNDMxLjUwMDAg NjMyLjc1MDAgTA0KICA0MzEuNTAwMCA2MzcuNzUwMCBMDQogIDQzMS41MDAwIDYzNy43NTAw IEwNCiAgNDMxLjUwMDAgNjM3Ljc1MDAgTA0KQg0KVQ0KdQ0KICAwLjAwMCAwLjAwMCAwLjAw MCAxLjAwMCBrDQogIDQxMS4yNTAwIDYyNy41MDAwIG0NCiAgNDA3LjAwMDAgNjI1LjI1MDAg TA0KICA0MDcuMDAwMCA2MjUuMjUwMCBMDQogIDQxMS4yNTAwIDYyMi43NTAwIEwNCiAgNDEx LjI1MDAgNjIyLjc1MDAgTA0KICA0MTEuMjUwMCA2MjcuNTAwMCBMDQogIDQxMS4yNTAwIDYy Ny41MDAwIEwNCiAgNDExLjI1MDAgNjI3LjUwMDAgTA0KQg0KVQ0KdQ0KICAwLjAwMCAwLjAw MCAwLjAwMCAxLjAwMCBrDQogIDQxNC4wMDAwIDYyMC41MDAwIG0NCiAgNDE2LjUwMDAgNjE2 LjAwMDAgTA0KICA0MTYuNTAwMCA2MTYuMDAwMCBMDQogIDQxOC43NTAwIDYyMC41MDAwIEwN CiAgNDE4Ljc1MDAgNjIwLjUwMDAgTA0KICA0MTQuMDAwMCA2MjAuNTAwMCBMDQogIDQxNC4w MDAwIDYyMC41MDAwIEwNCiAgNDE0LjAwMDAgNjIwLjUwMDAgTA0KQg0KVQ0KMCBUbw0KMSAw IDAgMSA0NjguNSA1NzEuNSAwIFRwDQpUUA0KL19IZWx2ZXRpY2EgNC43NTAwIFRmDQowLjAw MDAgVGMNCiAwIFRyDQogIDAuMDAwIDAuMDAwIDAuMDAwIDEuMDAwIEsNCiAgMC4wMDAgMC4w MDAgMC4wMDAgMS4wMDAgaw0KKE1vYmlsZSBIb3N0XHIpIFR4DQpUTw0KMCBUbw0KMSAwIDAg MSA0MDIuNSA2MDIuMjUgMCBUcA0KVFANCi9fSGVsdmV0aWNhIDYuMDAwMCBUZg0KMC4wMDAw IFRjDQogMCBUcg0KICAwLjAwMCAwLjAwMCAwLjAwMCAxLjAwMCBrDQooTW9iaWxlIFJvdXRl clxyKSBUeA0KVE8NCjAgVG8NCjEgMCAwIDEgMzU1LjUgNjQzLjUgMCBUcA0KVFANCi9fSGVs dmV0aWNhIDEwLjAwMDAgVGYNCi0wLjI1MDAgVGMNCiAwIFRyDQogIDAuMDAwIDAuMDAwIDAu MDAwIDEuMDAwIGsNCihJUHY2XHIpIFR4DQpUTw0KMCBUbw0KMSAwIDAgMSAyMzUuNSA3NDEg MCBUcA0KVFANCi9fSGVsdmV0aWNhIDYuMDAwMCBUZg0KMC4wMDAwIFRjDQogMCBUcg0KICAw LjAwMCAwLjAwMCAwLjAwMCAxLjAwMCBrDQooTW9iaWxlIEhvc3QncyBIb21lIEFnZW50XHIp IFR4DQpUTw0KICAwLjAwMCAwLjAwMCAwLjAwMCAwLjAwMCBrDQogIDAuMDAwIDAuMDAwIDAu MDAwIDEuMDAwIEsNCiAgMC4wMDAgMC4wMDAgMC4wMDAgMC4wMDAgaw0KICAwLjAwMCAwLjAw MCAwLjAwMCAwLjAwMCBrDQoqdQ0KICA3OS41MDAwIDY2Mi41MDAwIG0NCiAgODAuNzUwMCA2 NjIuNTAwMCAgODIuMDAwMCA2NjMuNzUwMCAgODIuMDAwMCA2NjUuMDAwMCBDDQogIDgyLjAw MDAgNjc1LjI1MDAgTA0KICA4Mi4wMDAwIDY3Ni43NTAwICA4MC43NTAwIDY3Ny43NTAwICA3 OS41MDAwIDY3Ny43NTAwIEMNCiAgNTkuMDAwMCA2NzcuNzUwMCBMDQogIDU3LjUwMDAgNjc3 Ljc1MDAgIDU2LjUwMDAgNjc2Ljc1MDAgIDU2LjUwMDAgNjc1LjI1MDAgQw0KICA1Ni41MDAw IDY2NS4wMDAwIEwNCiAgNTYuNTAwMCA2NjMuNzUwMCAgNTcuNTAwMCA2NjIuNTAwMCAgNTku MDAwMCA2NjIuNTAwMCBDDQogIDc5LjUwMDAgNjYyLjUwMDAgTA0KQg0KKlUNCiAgMC4wMDAg MC4wMDAgMC4wMDAgMC4wMDAgaw0KICAyOTUuMDAwMCA3NTAuMDAwMCBtDQogIDI5NS4wMDAw IDc0Ni41MDAwICAyOTEuMjUwMCA3NDQuMjUwMCAgMjg4LjI1MDAgNzQ2LjAwMDAgQw0KICAy ODUuMjUwMCA3NDcuNzUwMCAgMjg1LjI1MDAgNzUyLjAwMDAgIDI4OC4yNTAwIDc1My43NTAw IEMNCiAgMjkxLjI1MDAgNzU1LjUwMDAgIDI5NS4wMDAwIDc1My4yNTAwICAyOTUuMDAwMCA3 NTAuMDAwMCBDDQpCDQp1DQogIDI5NC43NTAwIDc1MS4yNTAwIG0NCiAgMzA5LjI1MDAgNjUw Ljc1MDAgTA0KICAzMTAuMDAwMCA2NDcuNTAwMCBMDQogIDMxMS4yNTAwIDY0NC43NTAwIEwN CiAgMzEyLjc1MDAgNjQyLjUwMDAgTA0KICAzMTUuMDAwMCA2NDAuMDAwMCBMDQogIDMxNy41 MDAwIDYzOC4wMDAwIEwNCiAgMzIwLjI1MDAgNjM2LjI1MDAgTA0KICAzMjMuMjUwMCA2MzUu MDAwMCBMDQogIDMyNy4wMDAwIDYzNC4wMDAwIEwNCiAgMzMxLjI1MDAgNjMzLjAwMDAgTA0K ICAzMzUuMjUwMCA2MzIuNTAwMCBMDQogIDMzNy4yNTAwIDYzMi41MDAwIEwNCiAgNDc5LjUw MDAgNjM4LjI1MDAgTA0KICA0ODEuNzUwMCA2MzguMjUwMCBMDQogIDQ4My41MDAwIDYzNy43 NTAwIEwNCiAgNDg1LjAwMDAgNjM3LjI1MDAgTA0KICA0ODYuNTAwMCA2MzYuMDAwMCBMDQog IDQ4Ny43NTAwIDYzNC41MDAwIEwNCiAgNDg4Ljc1MDAgNjMyLjI1MDAgTA0KICA0ODkuNTAw MCA2MzAuMDAwMCBMDQogIDQ5MC4wMDAwIDYyNy4yNTAwIEwNCiAgNDkwLjAwMDAgNjI0LjAw MDAgTA0KICA0OTAuMDAwMCA1ODQuMjUwMCBMDQogIDQ4OS4wMDAwIDU4Mi41MDAwIEwNCiAg NDg4LjAwMDAgNTgxLjUwMDAgTA0KICA0ODcuNTAwMCA1ODEuNTAwMCBMDQogIDQ4Ni43NTAw IDU4MS41MDAwIEwNCiAgNDg2LjAwMDAgNTgyLjAwMDAgTA0KICA0ODUuMDAwMCA1ODMuMjUw MCBMDQogIDQ4NC41MDAwIDU4NC4yNTAwIEwNClMNClUNCnUNCiAgMjg2LjAwMDAgNzUwLjAw MDAgbQ0KICAzMDAuNTAwMCA2NTAuMDAwMCBMDQogIDMwMS4yNTAwIDY0Ni41MDAwIEwNCiAg MzAyLjc1MDAgNjQyLjc1MDAgTA0KICAzMDQuNTAwMCA2MzkuNzUwMCBMDQogIDMwNi41MDAw IDYzNi43NTAwIEwNCiAgMzA5LjI1MDAgNjM0LjI1MDAgTA0KICAzMTIuMjUwMCA2MzIuMjUw MCBMDQogIDMxNS4yNTAwIDYzMC41MDAwIEwNCiAgMzE4LjAwMDAgNjI5LjI1MDAgTA0KICAz MjEuNTAwMCA2MjguMjUwMCBMDQogIDMyNC43NTAwIDYyNy41MDAwIEwNCiAgMzI5LjAwMDAg NjI3LjAwMDAgTA0KICAzMzQuMDAwMCA2MjYuNzUwMCBMDQogIDMzNy4yNTAwIDYyNi43NTAw IEwNCiAgNDc5LjAwMDAgNjMyLjUwMDAgTA0KICA0ODEuMDAwMCA2MzIuMDAwMCBMDQogIDQ4 Mi43NTAwIDYzMS4yNTAwIEwNCiAgNDg0LjAwMDAgNjMwLjAwMDAgTA0KICA0ODQuNzUwMCA2 MjkuMDAwMCBMDQogIDQ4NS4yNTAwIDYyNy41MDAwIEwNCiAgNDg1LjAwMDAgNjI2LjAwMDAg TA0KICA0ODQuNTAwMCA2MjQuMjUwMCBMDQogIDQ4NC41MDAwIDYyNC4wMDAwIEwNCiAgNDg0 LjUwMDAgNTg0LjI1MDAgTA0KUw0KVQ0KdQ0KICAwLjAwMCAwLjAwMCAwLjAwMCAxLjAwMCBr DQogIDI1Mi43NTAwIDc2OC41MDAwIG0NCiAgMjUzLjAwMDAgNzcxLjI1MDAgTA0KICAyNTMu MDAwMCA3NzEuMjUwMCBMDQogIDI1My4yNTAwIDc3My4wMDAwIEwNCiAgMjUzLjI1MDAgNzcz LjAwMDAgTA0KICAyNTMuNzUwMCA3NzQuNzUwMCBMDQogIDI1NC4yNTAwIDc3Ni41MDAwIEwN CiAgMjU0LjI1MDAgNzc2LjUwMDAgTA0KICAyNTUuMDAwMCA3NzguMDAwMCBMDQogIDI1NS4w MDAwIDc3OC4wMDAwIEwNCiAgMjU2LjAwMDAgNzc5LjUwMDAgTA0KICAyNTcuMDAwMCA3ODEu MDAwMCBMDQogIDI1Ny4wMDAwIDc4MC43NTAwIEwNCiAgMjU4LjI1MDAgNzgyLjI1MDAgTA0K ICAyNTkuNTAwMCA3ODMuNTAwMCBMDQogIDI1OS41MDAwIDc4My4yNTAwIEwNCiAgMjYxLjAw MDAgNzg0LjUwMDAgTA0KICAyNjAuNzUwMCA3ODQuNTAwMCBMDQogIDI2NC4wMDAwIDc4Ni4y NTAwIEwNCiAgMjY0LjAwMDAgNzg2LjAwMDAgTA0KICAyNjUuNzUwMCA3ODYuNzUwMCBMDQog IDI2Ny41MDAwIDc4Ny4yNTAwIEwNCiAgMjY3LjUwMDAgNzg3LjI1MDAgTA0KICAyNjkuMjUw MCA3ODcuNTAwMCBMDQogIDI2OS4yNTAwIDc4Ny41MDAwIEwNCiAgMjcxLjAwMDAgNzg3LjUw MDAgTA0KICAyNzMuMDAwMCA3ODcuNTAwMCBMDQogIDI3My4wMDAwIDc4Ny41MDAwIEwNCiAg Mjc0Ljc1MDAgNzg3LjI1MDAgTA0KICAyNzQuNzUwMCA3ODcuMjUwMCBMDQogIDI3Ni41MDAw IDc4Ni43NTAwIEwNCiAgMjc4LjI1MDAgNzg2LjAwMDAgTA0KICAyNzguMjUwMCA3ODYuMjUw MCBMDQogIDI3OS43NTAwIDc4NS4yNTAwIEwNCiAgMjc5Ljc1MDAgNzg1LjI1MDAgTA0KICAy ODEuMjUwMCA3ODQuNTAwMCBMDQogIDI4Mi43NTAwIDc4My4yNTAwIEwNCiAgMjgyLjc1MDAg NzgzLjUwMDAgTA0KICAyODQuMDAwMCA3ODIuMjUwMCBMDQogIDI4NS4yNTAwIDc4MC43NTAw IEwNCiAgMjg1LjI1MDAgNzgxLjAwMDAgTA0KICAyODYuMjUwMCA3NzkuNTAwMCBMDQogIDI4 Ny4yNTAwIDc3OC4wMDAwIEwNCiAgMjg3LjI1MDAgNzc4LjAwMDAgTA0KICAyODguMDAwMCA3 NzYuNTAwMCBMDQogIDI4OC4wMDAwIDc3Ni41MDAwIEwNCiAgMjg4LjUwMDAgNzc0Ljc1MDAg TA0KICAyODkuMDAwMCA3NzMuMDAwMCBMDQogIDI4OS4wMDAwIDc3My4wMDAwIEwNCiAgMjg5 LjI1MDAgNzcxLjI1MDAgTA0KICAyODkuMjUwMCA3NzEuMjUwMCBMDQogIDI4OS4yNTAwIDc2 OS4yNTAwIEwNCiAgMjg5LjI1MDAgNzY3LjUwMDAgTA0KICAyODkuMjUwMCA3NjcuNTAwMCBM DQogIDI4OS4wMDAwIDc2NS43NTAwIEwNCiAgMjg5LjAwMDAgNzY1Ljc1MDAgTA0KICAyODgu NTAwMCA3NjQuMDAwMCBMDQogIDI4OC4wMDAwIDc2Mi4yNTAwIEwNCiAgMjg4LjAwMDAgNzYy LjI1MDAgTA0KICAyODcuMjUwMCA3NjAuNzUwMCBMDQogIDI4Ny4yNTAwIDc2MC43NTAwIEwN CiAgMjg2LjI1MDAgNzU5LjI1MDAgTA0KICAyODUuMjUwMCA3NTcuNzUwMCBMDQogIDI4NS4y NTAwIDc1Ny43NTAwIEwNCiAgMjg0LjAwMDAgNzU2LjUwMDAgTA0KICAyODIuNzUwMCA3NTUu MjUwMCBMDQogIDI4Mi43NTAwIDc1NS41MDAwIEwNCiAgMjgxLjI1MDAgNzU0LjI1MDAgTA0K ICAyNzkuNzUwMCA3NTMuNTAwMCBMDQogIDI3OS43NTAwIDc1My41MDAwIEwNCiAgMjc4LjI1 MDAgNzUyLjUwMDAgTA0KICAyNzguMjUwMCA3NTIuNzUwMCBMDQogIDI3Ni41MDAwIDc1Mi4w MDAwIEwNCiAgMjc0Ljc1MDAgNzUxLjUwMDAgTA0KICAyNzQuNzUwMCA3NTEuNTAwMCBMDQog IDI3My4wMDAwIDc1MS4yNTAwIEwNCiAgMjczLjAwMDAgNzUxLjI1MDAgTA0KICAyNzEuMDAw MCA3NTEuMjUwMCBMDQogIDI2OS4yNTAwIDc1MS4yNTAwIEwNCiAgMjY5LjI1MDAgNzUxLjI1 MDAgTA0KICAyNjcuNTAwMCA3NTEuNTAwMCBMDQogIDI2Ny41MDAwIDc1MS41MDAwIEwNCiAg MjY1Ljc1MDAgNzUyLjAwMDAgTA0KICAyNjQuMDAwMCA3NTIuNzUwMCBMDQogIDI2NC4wMDAw IDc1Mi41MDAwIEwNCiAgMjYwLjc1MDAgNzU0LjI1MDAgTA0KICAyNjEuMDAwMCA3NTQuMjUw MCBMDQogIDI1OC4yNTAwIDc1Ni41MDAwIEwNCiAgMjU3LjAwMDAgNzU3Ljc1MDAgTA0KICAy NTcuMDAwMCA3NTcuNzUwMCBMDQogIDI1Ni4wMDAwIDc1OS4yNTAwIEwNCiAgMjU1LjAwMDAg NzYwLjc1MDAgTA0KICAyNTUuMDAwMCA3NjAuNzUwMCBMDQogIDI1NC4yNTAwIDc2Mi4yNTAw IEwNCiAgMjU0LjI1MDAgNzYyLjI1MDAgTA0KICAyNTMuNzUwMCA3NjQuMDAwMCBMDQogIDI1 My4yNTAwIDc2NS43NTAwIEwNCiAgMjUzLjI1MDAgNzY1Ljc1MDAgTA0KICAyNTIuNzUwMCA3 NjkuNTAwMCBMDQogIDI1Mi43NTAwIDc2OS43NTAwIEwNCiAgMjUyLjAwMDAgNzY5LjAwMDAg TA0KICAyNTIuNzUwMCA3NjguNTAwMCBMDQogIDI1Mi43NTAwIDc2OS43NTAwIEwNCiAgMjUy Ljc1MDAgNzY5Ljc1MDAgTA0KICAyNTIuMDAwMCA3NjkuMDAwMCBMDQogIDI1Mi4yNTAwIDc2 OS4wMDAwIEwNCiAgMjUyLjAwMDAgNzY5LjI1MDAgTA0KICAyNTIuMjUwMCA3NjcuNTAwMCBM DQogIDI1Mi41MDAwIDc2NS41MDAwIEwNCiAgMjUyLjc1MDAgNzYzLjc1MDAgTA0KICAyNTQu MjUwMCA3NjAuMjUwMCBMDQogIDI1Ni41MDAwIDc1Ny4yNTAwIEwNCiAgMjU3LjUwMDAgNzU2 LjAwMDAgTA0KICAyNjAuNTAwMCA3NTMuNTAwMCBMDQogIDI2My43NTAwIDc1MS43NTAwIEwN CiAgMjY1LjUwMDAgNzUxLjI1MDAgTA0KICAyNjcuMjUwMCA3NTAuNzUwMCBMDQogIDI2OS4y NTAwIDc1MC41MDAwIEwNCiAgMjcxLjAwMDAgNzUwLjI1MDAgTA0KICAyNzMuMDAwMCA3NTAu NTAwMCBMDQogIDI3NS4wMDAwIDc1MC43NTAwIEwNCiAgMjc2Ljc1MDAgNzUxLjI1MDAgTA0K ICAyNzguNTAwMCA3NTEuNzUwMCBMDQogIDI4MS43NTAwIDc1My41MDAwIEwNCiAgMjgzLjI1 MDAgNzU0Ljc1MDAgTA0KICAyODYuMDAwMCA3NTcuMjUwMCBMDQogIDI4Ny4wMDAwIDc1OC43 NTAwIEwNCiAgMjg4Ljc1MDAgNzYyLjAwMDAgTA0KICAyODkuNTAwMCA3NjMuNzUwMCBMDQog IDI4OS43NTAwIDc2NS41MDAwIEwNCiAgMjkwLjI1MDAgNzY5LjI1MDAgTA0KICAyODkuNzUw MCA3NzMuMjUwMCBMDQogIDI4OS41MDAwIDc3NS4wMDAwIEwNCiAgMjg4Ljc1MDAgNzc2Ljc1 MDAgTA0KICAyODcuMDAwMCA3ODAuMDAwMCBMDQogIDI4NS43NTAwIDc4MS41MDAwIEwNCiAg MjgzLjI1MDAgNzg0LjAwMDAgTA0KICAyODEuNzUwMCA3ODUuMjUwMCBMDQogIDI3OC41MDAw IDc4Ny4wMDAwIEwNCiAgMjc2Ljc1MDAgNzg3LjUwMDAgTA0KICAyNzUuMDAwMCA3ODguMDAw MCBMDQogIDI3My4wMDAwIDc4OC4yNTAwIEwNCiAgMjcxLjAwMDAgNzg4LjUwMDAgTA0KICAy NjkuMjUwMCA3ODguMjUwMCBMDQogIDI2Ny4yNTAwIDc4OC4wMDAwIEwNCiAgMjY1LjUwMDAg Nzg3LjUwMDAgTA0KICAyNjMuNzUwMCA3ODYuNzUwMCBMDQogIDI2MC41MDAwIDc4NS4yNTAw IEwNCiAgMjU3LjUwMDAgNzgyLjc1MDAgTA0KICAyNTYuMjUwMCA3ODEuNTAwMCBMDQogIDI1 NC4yNTAwIDc3OC41MDAwIEwNCiAgMjUyLjc1MDAgNzc1LjAwMDAgTA0KICAyNTIuNTAwMCA3 NzMuMjUwMCBMDQogIDI1Mi4yNTAwIDc3MS4yNTAwIEwNCiAgMjUyLjAwMDAgNzY5LjI1MDAg TA0KICAyNTIuNzUwMCA3NjkuNzUwMCBMDQogIDI1Mi43NTAwIDc2OC41MDAwIEwNCkYNClUN CnUNCiAgMC4wMDAgMC4wMDAgMC4wMDAgMS4wMDAgaw0KICAyNjcuMDAwMCA3NTkuMjUwMCBt DQogIDI2Ny4wMDAwIDc2Ny41MDAwIEwNCiAgMjY2LjUwMDAgNzY3LjAwMDAgTA0KICAyNjcu MDAwMCA3NjcuMDAwMCBMDQogIDI2Ny4yNTAwIDc2OC43NTAwIEwNCiAgMjY3LjI1MDAgNzY4 Ljc1MDAgTA0KICAyNjcuNzUwMCA3NzAuMDAwMCBMDQogIDI2Ny41MDAwIDc3MC4wMDAwIEwN CiAgMjY4LjI1MDAgNzcxLjAwMDAgTA0KICAyNjguMDAwMCA3NzEuMDAwMCBMDQogIDI2OS4w MDAwIDc3Mi4wMDAwIEwNCiAgMjY4Ljc1MDAgNzcyLjAwMDAgTA0KICAyNjkuNzUwMCA3NzIu NzUwMCBMDQogIDI2OS43NTAwIDc3Mi41MDAwIEwNCiAgMjcxLjAwMDAgNzczLjI1MDAgTA0K ICAyNzAuNzUwMCA3NzMuMjUwMCBMDQogIDI3Mi4wMDAwIDc3My41MDAwIEwNCiAgMjcyLjAw MDAgNzczLjUwMDAgTA0KICAyNzMuMjUwMCA3NzMuNzUwMCBMDQogIDI3My4yNTAwIDc3NC41 MDAwIEwNCiAgMjczLjI1MDAgNzc0LjUwMDAgTA0KICAyNzMuMjUwMCA3NzMuNzUwMCBMDQog IDI4MS41MDAwIDc3My43NTAwIEwNCiAgMjgxLjUwMDAgNzc0LjUwMDAgTA0KICAyNzMuMjUw MCA3NzQuNTAwMCBMDQogIDI3My4yNTAwIDc3My43NTAwIEwNCiAgMjczLjI1MDAgNzczLjc1 MDAgTA0KICAyNzMuMjUwMCA3NzQuNTAwMCBMDQogIDI3Mi4wMDAwIDc3NC41MDAwIEwNCiAg MjcwLjUwMDAgNzc0LjAwMDAgTA0KICAyNjkuMjUwMCA3NzMuNTAwMCBMDQogIDI2OC4yNTAw IDc3Mi41MDAwIEwNCiAgMjY3LjUwMDAgNzcxLjUwMDAgTA0KICAyNjYuNzUwMCA3NzAuMjUw MCBMDQogIDI2Ni4yNTAwIDc2OS4wMDAwIEwNCiAgMjY2LjI1MDAgNzY3LjUwMDAgTA0KICAy NjYuNzUwMCA3NjguMDAwMCBMDQogIDI2Ni4yNTAwIDc2OC4wMDAwIEwNCiAgMjY2LjAwMDAg NzU5LjI1MDAgTA0KICAyNjcuMDAwMCA3NTkuMjUwMCBMDQpGDQpVDQp1DQogIDAuMDAwIDAu MDAwIDAuMDAwIDEuMDAwIGsNCiAgMjc1Ljc1MDAgNzc5LjUwMDAgbQ0KICAyNzUuNzUwMCA3 NzAuNTAwMCBMDQogIDI3Ni4yNTAwIDc3MC41MDAwIEwNCiAgMjc1Ljc1MDAgNzcxLjAwMDAg TA0KICAyNzUuNzUwMCA3NjkuNTAwMCBMDQogIDI3NS43NTAwIDc2OS43NTAwIEwNCiAgMjc1 LjI1MDAgNzY4LjI1MDAgTA0KICAyNzUuMjUwMCA3NjguNTAwMCBMDQogIDI3NC43NTAwIDc2 Ny4yNTAwIEwNCiAgMjc0Ljc1MDAgNzY3LjI1MDAgTA0KICAyNzQuMDAwMCA3NjYuMjUwMCBM DQogIDI3NC4wMDAwIDc2Ni4yNTAwIEwNCiAgMjczLjAwMDAgNzY1LjUwMDAgTA0KICAyNzMu MDAwMCA3NjUuNTAwMCBMDQogIDI3MS43NTAwIDc2NS4wMDAwIEwNCiAgMjcyLjAwMDAgNzY1 LjAwMDAgTA0KICAyNzAuNTAwMCA3NjQuNTAwMCBMDQogIDI3MC43NTAwIDc2NC41MDAwIEwN CiAgMjY5LjI1MDAgNzY0LjUwMDAgTA0KICAyNjkuMjUwMCA3NjQuNTAwMCBMDQogIDI2MC43 NTAwIDc2NC41MDAwIEwNCiAgMjYwLjc1MDAgNzYzLjUwMDAgTA0KICAyNjkuNTAwMCA3NjMu NTAwMCBMDQogIDI3MC43NTAwIDc2My43NTAwIEwNCiAgMjcyLjI1MDAgNzY0LjI1MDAgTA0K ICAyNzMuNTAwMCA3NjQuNzUwMCBMDQogIDI3NC41MDAwIDc2NS43NTAwIEwNCiAgMjc1LjUw MDAgNzY2Ljc1MDAgTA0KICAyNzYuMjUwMCA3NjguMDAwMCBMDQogIDI3Ni41MDAwIDc2OS41 MDAwIEwNCiAgMjc2Ljc1MDAgNzcxLjUwMDAgTA0KICAyNzYuMjUwMCA3NzEuNTAwMCBMDQog IDI3Ni43NTAwIDc3MS4wMDAwIEwNCiAgMjc2Ljc1MDAgNzc5LjUwMDAgTA0KICAyNzUuNzUw MCA3NzkuNTAwMCBMDQpGDQpVDQp1DQogIDAuMDAwIDAuMDAwIDAuMDAwIDEuMDAwIGsNCiAg MjczLjI1MDAgNzgwLjAwMDAgbQ0KICAyNzUuNzUwMCA3ODQuMjUwMCBMDQogIDI3NS43NTAw IDc4NC4yNTAwIEwNCiAgMjc4LjAwMDAgNzgwLjAwMDAgTA0KICAyNzguMDAwMCA3ODAuMDAw MCBMDQogIDI3My4yNTAwIDc4MC4wMDAwIEwNCiAgMjczLjI1MDAgNzgwLjAwMDAgTA0KICAy NzMuMjUwMCA3ODAuMDAwMCBMDQpCDQpVDQp1DQogIDAuMDAwIDAuMDAwIDAuMDAwIDEuMDAw IGsNCiAgMjgxLjI1MDAgNzc2LjUwMDAgbQ0KICAyODUuNzUwMCA3NzQuMDAwMCBMDQogIDI4 NS43NTAwIDc3NC4wMDAwIEwNCiAgMjgxLjI1MDAgNzcxLjUwMDAgTA0KICAyODEuMjUwMCA3 NzEuNTAwMCBMDQogIDI4MS4yNTAwIDc3Ni41MDAwIEwNCiAgMjgxLjI1MDAgNzc2LjUwMDAg TA0KICAyODEuMjUwMCA3NzYuNTAwMCBMDQpCDQpVDQp1DQogIDAuMDAwIDAuMDAwIDAuMDAw IDEuMDAwIGsNCiAgMjYxLjAwMDAgNzY2LjUwMDAgbQ0KICAyNTYuNzUwMCA3NjQuMDAwMCBM DQogIDI1Ni43NTAwIDc2NC4wMDAwIEwNCiAgMjYxLjAwMDAgNzYxLjc1MDAgTA0KICAyNjEu MDAwMCA3NjEuNzUwMCBMDQogIDI2MS4wMDAwIDc2Ni41MDAwIEwNCiAgMjYxLjAwMDAgNzY2 LjUwMDAgTA0KICAyNjEuMDAwMCA3NjYuNTAwMCBMDQpCDQpVDQp1DQogIDAuMDAwIDAuMDAw IDAuMDAwIDEuMDAwIGsNCiAgMjYzLjc1MDAgNzU5LjI1MDAgbQ0KICAyNjYuMjUwMCA3NTUu MDAwMCBMDQogIDI2Ni4yNTAwIDc1NS4wMDAwIEwNCiAgMjY4Ljc1MDAgNzU5LjI1MDAgTA0K ICAyNjguNzUwMCA3NTkuMjUwMCBMDQogIDI2My43NTAwIDc1OS4yNTAwIEwNCiAgMjYzLjc1 MDAgNzU5LjI1MDAgTA0KICAyNjMuNzUwMCA3NTkuMjUwMCBMDQpCDQpVDQp1DQogIDQ4Ny4y NTAwIDU4MS41MDAwIG0NCiAgNDg3LjI1MDAgNTc1Ljc1MDAgTA0KUw0KVQ0KdQ0KICAwLjAw MCAwLjAwMCAwLjAwMCAxLjAwMCBrDQogIDQ4OC43NTAwIDU3Ny4yNTAwIG0NCiAgNDg3LjI1 MDAgNTc1Ljc1MDAgTA0KICA0ODUuNzUwMCA1NzcuMjUwMCBMDQogIDQ4OC43NTAwIDU3Ny4y NTAwIEwNCkINClUNCjAgVG8NCjEgMCAwIDEgNDQ3LjI1IDU1NS43NSAwIFRwDQpUUA0KL19I ZWx2ZXRpY2EgMTAuMDAwMCBUZg0KMC4wMDAwIFRjDQogMCBUcg0KICAwLjAwMCAwLjAwMCAw LjAwMCAxLjAwMCBLDQogIDAuMDAwIDAuMDAwIDAuMDAwIDEuMDAwIGsNCihNb2JpbGUgTmV0 d29ya1xyKSBUeA0KVE8NCnUNCiAgMC4wMDAgMC4wMDAgMC4wMDAgMS4wMDAgSw0KICA4Mi4w MDAwIDY3Mi4yNTAwIG0NCiAgMjc1LjAwMDAgNzYwLjI1MDAgTA0KICAyNzcuNTAwMCA3NjEu MDAwMCBMDQogIDI4MC4wMDAwIDc2MS41MDAwIEwNCiAgMjgxLjc1MDAgNzYxLjUwMDAgTA0K ICAyODMuNTAwMCA3NjEuMjUwMCBMDQogIDI4NS4yNTAwIDc2MC41MDAwIEwNCiAgMjg3LjAw MDAgNzU5LjI1MDAgTA0KICAyODguNTAwMCA3NTcuNzUwMCBMDQogIDI4OS43NTAwIDc1NS41 MDAwIEwNCiAgMjkxLjAwMDAgNzUyLjI1MDAgTA0KICAyOTEuNTAwMCA3NDkuMjUwMCBMDQog IDI5MS43NTAwIDc0OC43NTAwIEwNClMNClUNCnUNCiAgNDc2LjAwMDAgNTg0LjI1MDAgbQ0K ICA0NzYuMDAwMCA2MjQuMDAwMCBMDQogIDQ3Ni4wMDAwIDYyNC4wMDAwIEwNCiAgNDc1Ljc1 MDAgNjI0LjUwMDAgTA0KICA0NzUuNTAwMCA2MjUuMDAwMCBMDQogIDQ3NS4yNTAwIDYyNS41 MDAwIEwNCiAgNDc0Ljc1MDAgNjI1Ljc1MDAgTA0KICA0NzQuNTAwMCA2MjYuMDAwMCBMDQog IDQ3NC4wMDAwIDYyNi41MDAwIEwNCiAgNDczLjUwMDAgNjI2Ljc1MDAgTA0KICA0NzMuMDAw MCA2MjYuNzUwMCBMDQogIDQ3My4wMDAwIDYyNi43NTAwIEwNCiAgNDczLjAwMDAgNjI2Ljc1 MDAgTA0KICA0NzIuNTAwMCA2MjcuMDAwMCBMDQogIDQ3Mi4wMDAwIDYyNy4wMDAwIEwNCiAg NDcxLjI1MDAgNjI3LjI1MDAgTA0KICA0NzAuMDAwMCA2MjcuMjUwMCBMDQogIDQ2OS4wMDAw IDYyNy4wMDAwIEwNCiAgNDY4LjI1MDAgNjI3LjAwMDAgTA0KICA0NjcuNTAwMCA2MjYuNzUw MCBMDQogIDQ2Ny41MDAwIDYyNi43NTAwIEwNCiAgNDY3LjUwMDAgNjI2Ljc1MDAgTA0KICAz MTcuMjUwMCA2MjEuMjUwMCBMDQogIDMxNy4yNTAwIDYyMS4yNTAwIEwNCiAgMzA4Ljc1MDAg NjIyLjUwMDAgTA0KICAzMDAuMjUwMCA2MjQuMDAwMCBMDQogIDMwMC4yNTAwIDYyNC4wMDAw IEwNCiAgMzAwLjI1MDAgNjI0LjAwMDAgTA0KICAyOTEuNzUwMCA2MjUuNTAwMCBMDQogIDI4 My4yNTAwIDYyNi43NTAwIEwNCiAgMjgzLjI1MDAgNjI2Ljc1MDAgTA0KICAyODMuMjUwMCA2 MjYuNzUwMCBMDQogIDgyLjAwMDAgNjY5LjI1MDAgTA0KICA4Mi4wMDAwIDY2OS4yNTAwIEwN ClMNClUNCnUNCiAgMC4wMDAgMC4wMDAgMC4wMDAgMS4wMDAgaw0KICAyOTUuNTAwMCA2Mjku NTAwMCBtDQogIDI5NS43NTAwIDYzMi4yNTAwIEwNCiAgMjk1Ljc1MDAgNjMyLjI1MDAgTA0K ICAyOTYuMDAwMCA2MzQuMDAwMCBMDQogIDI5Ni4wMDAwIDYzNC4wMDAwIEwNCiAgMjk2LjUw MDAgNjM1Ljc1MDAgTA0KICAyOTcuMDAwMCA2MzcuNTAwMCBMDQogIDI5Ny4wMDAwIDYzNy41 MDAwIEwNCiAgMjk3Ljc1MDAgNjM5LjAwMDAgTA0KICAyOTcuNzUwMCA2MzkuMDAwMCBMDQog IDI5OC43NTAwIDY0MC41MDAwIEwNCiAgMjk5Ljc1MDAgNjQyLjAwMDAgTA0KICAyOTkuNzUw MCA2NDIuMDAwMCBMDQogIDMwMS4wMDAwIDY0My4yNTAwIEwNCiAgMzAzLjUwMDAgNjQ1LjUw MDAgTA0KICAzMDMuNTAwMCA2NDUuNTAwMCBMDQogIDMwNi43NTAwIDY0Ny4yNTAwIEwNCiAg MzA2Ljc1MDAgNjQ3LjAwMDAgTA0KICAzMDguNTAwMCA2NDcuNzUwMCBMDQogIDMxMC4yNTAw IDY0OC4yNTAwIEwNCiAgMzEwLjI1MDAgNjQ4LjI1MDAgTA0KICAzMTIuMDAwMCA2NDguNTAw MCBMDQogIDMxMi4wMDAwIDY0OC41MDAwIEwNCiAgMzEzLjc1MDAgNjQ4LjUwMDAgTA0KICAz MTUuNzUwMCA2NDguNTAwMCBMDQogIDMxNS43NTAwIDY0OC41MDAwIEwNCiAgMzE3LjUwMDAg NjQ4LjI1MDAgTA0KICAzMTcuNTAwMCA2NDguMjUwMCBMDQogIDMxOS4yNTAwIDY0Ny43NTAw IEwNCiAgMzIxLjAwMDAgNjQ3LjAwMDAgTA0KICAzMjEuMDAwMCA2NDcuMjUwMCBMDQogIDMy Mi41MDAwIDY0Ni4yNTAwIEwNCiAgMzIyLjUwMDAgNjQ2LjI1MDAgTA0KICAzMjQuMDAwMCA2 NDUuNTAwMCBMDQogIDMyNS41MDAwIDY0NC4yNTAwIEwNCiAgMzI1LjUwMDAgNjQ0LjUwMDAg TA0KICAzMjYuNzUwMCA2NDMuMjUwMCBMDQogIDMyOC4wMDAwIDY0Mi4wMDAwIEwNCiAgMzI3 Ljc1MDAgNjQyLjAwMDAgTA0KICAzMjkuMDAwMCA2NDAuNTAwMCBMDQogIDMyOS43NTAwIDYz OS4wMDAwIEwNCiAgMzI5Ljc1MDAgNjM5LjAwMDAgTA0KICAzMzAuNzUwMCA2MzcuNTAwMCBM DQogIDMzMC41MDAwIDYzNy41MDAwIEwNCiAgMzMxLjI1MDAgNjM1Ljc1MDAgTA0KICAzMzEu NzUwMCA2MzQuMDAwMCBMDQogIDMzMS43NTAwIDYzNC4wMDAwIEwNCiAgMzMyLjAwMDAgNjMy LjI1MDAgTA0KICAzMzIuMDAwMCA2MzIuMjUwMCBMDQogIDMzMi4wMDAwIDYzMC41MDAwIEwN CiAgMzMyLjAwMDAgNjI4LjUwMDAgTA0KICAzMzIuMDAwMCA2MjguNTAwMCBMDQogIDMzMS43 NTAwIDYyNi43NTAwIEwNCiAgMzMxLjc1MDAgNjI2Ljc1MDAgTA0KICAzMzEuMjUwMCA2MjUu MDAwMCBMDQogIDMzMC41MDAwIDYyMy4yNTAwIEwNCiAgMzMwLjc1MDAgNjIzLjI1MDAgTA0K ICAzMjkuNzUwMCA2MjEuNzUwMCBMDQogIDMyOS43NTAwIDYyMS43NTAwIEwNCiAgMzI5LjAw MDAgNjIwLjI1MDAgTA0KICAzMjcuNzUwMCA2MTguNzUwMCBMDQogIDMyOC4wMDAwIDYxOS4w MDAwIEwNCiAgMzI2Ljc1MDAgNjE3LjUwMDAgTA0KICAzMjUuNTAwMCA2MTYuMjUwMCBMDQog IDMyNS41MDAwIDYxNi41MDAwIEwNCiAgMzI0LjAwMDAgNjE1LjI1MDAgTA0KICAzMjEuMDAw MCA2MTMuNzUwMCBMDQogIDMyMS4wMDAwIDYxMy43NTAwIEwNCiAgMzE5LjI1MDAgNjEzLjAw MDAgTA0KICAzMTcuNTAwMCA2MTIuNzUwMCBMDQogIDMxNy41MDAwIDYxMi43NTAwIEwNCiAg MzE1Ljc1MDAgNjEyLjUwMDAgTA0KICAzMTUuNzUwMCA2MTIuNTAwMCBMDQogIDMxMy43NTAw IDYxMi4yNTAwIEwNCiAgMzEyLjAwMDAgNjEyLjUwMDAgTA0KICAzMTIuMDAwMCA2MTIuNTAw MCBMDQogIDMxMC4yNTAwIDYxMi43NTAwIEwNCiAgMzEwLjI1MDAgNjEyLjc1MDAgTA0KICAz MDguNTAwMCA2MTMuMDAwMCBMDQogIDMwNi43NTAwIDYxMy43NTAwIEwNCiAgMzA2Ljc1MDAg NjEzLjc1MDAgTA0KICAzMDMuNTAwMCA2MTUuMjUwMCBMDQogIDMwMy41MDAwIDYxNS4yNTAw IEwNCiAgMzAxLjAwMDAgNjE3LjUwMDAgTA0KICAyOTkuNzUwMCA2MTkuMDAwMCBMDQogIDI5 OS43NTAwIDYxOC43NTAwIEwNCiAgMjk4Ljc1MDAgNjIwLjI1MDAgTA0KICAyOTcuNzUwMCA2 MjEuNzUwMCBMDQogIDI5Ny43NTAwIDYyMS43NTAwIEwNCiAgMjk3LjAwMDAgNjIzLjI1MDAg TA0KICAyOTcuMDAwMCA2MjMuMjUwMCBMDQogIDI5Ni41MDAwIDYyNS4wMDAwIEwNCiAgMjk2 LjAwMDAgNjI2Ljc1MDAgTA0KICAyOTYuMDAwMCA2MjYuNzUwMCBMDQogIDI5NS41MDAwIDYz MC41MDAwIEwNCiAgMjk1LjUwMDAgNjMwLjc1MDAgTA0KICAyOTQuNzUwMCA2MzAuMjUwMCBM DQogIDI5NS41MDAwIDYyOS41MDAwIEwNCiAgMjk1LjUwMDAgNjMwLjc1MDAgTA0KICAyOTUu NTAwMCA2MzAuNzUwMCBMDQogIDI5NC43NTAwIDYzMC4yNTAwIEwNCiAgMjk0Ljc1MDAgNjMw LjAwMDAgTA0KICAyOTQuNzUwMCA2MzAuNTAwMCBMDQogIDI5NC43NTAwIDYyOC41MDAwIEwN CiAgMjk1LjI1MDAgNjI2LjUwMDAgTA0KICAyOTUuNTAwMCA2MjQuNzUwMCBMDQogIDI5Ny4w MDAwIDYyMS4yNTAwIEwNCiAgMjk5LjI1MDAgNjE4LjI1MDAgTA0KICAzMDAuMjUwMCA2MTcu MDAwMCBMDQogIDMwMy4wMDAwIDYxNC41MDAwIEwNCiAgMzA2LjUwMDAgNjEyLjc1MDAgTA0K ICAzMDguMDAwMCA2MTIuMjUwMCBMDQogIDMxMC4wMDAwIDYxMS43NTAwIEwNCiAgMzEyLjAw MDAgNjExLjUwMDAgTA0KICAzMTMuNzUwMCA2MTEuNTAwMCBMDQogIDMxNS43NTAwIDYxMS41 MDAwIEwNCiAgMzE3Ljc1MDAgNjExLjc1MDAgTA0KICAzMTkuNTAwMCA2MTIuMjUwMCBMDQog IDMyMS4yNTAwIDYxMy4wMDAwIEwNCiAgMzIzLjAwMDAgNjEzLjc1MDAgTA0KICAzMjQuNTAw MCA2MTQuNTAwMCBMDQogIDMyNi4wMDAwIDYxNS43NTAwIEwNCiAgMzI4Ljc1MDAgNjE4LjI1 MDAgTA0KICAzMjkuNzUwMCA2MTkuNzUwMCBMDQogIDMzMS41MDAwIDYyMy4wMDAwIEwNCiAg MzMyLjI1MDAgNjI0Ljc1MDAgTA0KICAzMzIuNTAwMCA2MjYuNTAwMCBMDQogIDMzMi43NTAw IDYyOC41MDAwIEwNCiAgMzMzLjAwMDAgNjMwLjUwMDAgTA0KICAzMzIuNTAwMCA2MzQuMjUw MCBMDQogIDMzMi4yNTAwIDYzNi4wMDAwIEwNCiAgMzMxLjUwMDAgNjM3Ljc1MDAgTA0KICAz MjkuNzUwMCA2NDEuMDAwMCBMDQogIDMyOC41MDAwIDY0Mi41MDAwIEwNCiAgMzI2LjAwMDAg NjQ1LjI1MDAgTA0KICAzMjQuNTAwMCA2NDYuMjUwMCBMDQogIDMyMS4yNTAwIDY0OC4wMDAw IEwNCiAgMzE5LjUwMDAgNjQ4LjUwMDAgTA0KICAzMTcuNzUwMCA2NDkuMDAwMCBMDQogIDMx NS43NTAwIDY0OS4yNTAwIEwNCiAgMzEzLjc1MDAgNjQ5LjUwMDAgTA0KICAzMTEuNzUwMCA2 NDkuMjUwMCBMDQogIDMxMC4wMDAwIDY0OS4wMDAwIEwNCiAgMzA4LjAwMDAgNjQ4LjUwMDAg TA0KICAzMDYuMjUwMCA2NDguMDAwMCBMDQogIDMwMy4wMDAwIDY0Ni4yNTAwIEwNCiAgMzAw LjI1MDAgNjQzLjc1MDAgTA0KICAyOTkuMDAwMCA2NDIuNTAwMCBMDQogIDI5Ny4wMDAwIDYz OS41MDAwIEwNCiAgMjk1LjUwMDAgNjM2LjAwMDAgTA0KICAyOTUuMjUwMCA2MzQuMjUwMCBM DQogIDI5NC43NTAwIDYzMi4yNTAwIEwNCiAgMjk0Ljc1MDAgNjMwLjUwMDAgTA0KICAyOTUu NTAwMCA2MzAuNzUwMCBMDQogIDI5NS41MDAwIDYyOS41MDAwIEwNCkYNClUNCnUNCiAgMC4w MDAgMC4wMDAgMC4wMDAgMS4wMDAgaw0KICAzMDkuNzUwMCA2MjAuNTAwMCBtDQogIDMwOS43 NTAwIDYyOC41MDAwIEwNCiAgMzA5LjI1MDAgNjI4LjAwMDAgTA0KICAzMDkuNzUwMCA2Mjgu MDAwMCBMDQogIDMxMC4wMDAwIDYyOS43NTAwIEwNCiAgMzEwLjAwMDAgNjI5Ljc1MDAgTA0K ICAzMTAuMjUwMCA2MzEuMDAwMCBMDQogIDMxMC4yNTAwIDYzMS4wMDAwIEwNCiAgMzExLjAw MDAgNjMyLjAwMDAgTA0KICAzMTAuNzUwMCA2MzIuMDAwMCBMDQogIDMxMS43NTAwIDYzMy4w MDAwIEwNCiAgMzExLjUwMDAgNjMzLjAwMDAgTA0KICAzMTIuNTAwMCA2MzMuNzUwMCBMDQog IDMxMi41MDAwIDYzMy43NTAwIEwNCiAgMzEzLjUwMDAgNjM0LjI1MDAgTA0KICAzMTMuNTAw MCA2MzQuMjUwMCBMDQogIDMxNC43NTAwIDYzNC41MDAwIEwNCiAgMzE0Ljc1MDAgNjM0LjUw MDAgTA0KICAzMTYuMDAwMCA2MzQuNzUwMCBMDQogIDMxNi4wMDAwIDYzNS43NTAwIEwNCiAg MzE2LjAwMDAgNjM1Ljc1MDAgTA0KICAzMTYuMDAwMCA2MzQuNzUwMCBMDQogIDMyNC4wMDAw IDYzNC43NTAwIEwNCiAgMzI0LjAwMDAgNjM1Ljc1MDAgTA0KICAzMTYuMDAwMCA2MzUuNzUw MCBMDQogIDMxNi4wMDAwIDYzNC43NTAwIEwNCiAgMzE2LjAwMDAgNjM0Ljc1MDAgTA0KICAz MTYuMDAwMCA2MzUuNzUwMCBMDQogIDMxNC41MDAwIDYzNS41MDAwIEwNCiAgMzEzLjI1MDAg NjM1LjAwMDAgTA0KICAzMTIuMDAwMCA2MzQuNTAwMCBMDQogIDMxMS4wMDAwIDYzMy41MDAw IEwNCiAgMzEwLjAwMDAgNjMyLjUwMDAgTA0KICAzMDkuNTAwMCA2MzEuMjUwMCBMDQogIDMw OS4wMDAwIDYzMC4wMDAwIEwNCiAgMzA5LjAwMDAgNjI4LjUwMDAgTA0KICAzMDkuMjUwMCA2 MjkuMDAwMCBMDQogIDMwOS4wMDAwIDYyOS4wMDAwIEwNCiAgMzA4Ljc1MDAgNjIwLjUwMDAg TA0KICAzMDkuNzUwMCA2MjAuNTAwMCBMDQpGDQpVDQp1DQogIDAuMDAwIDAuMDAwIDAuMDAw IDEuMDAwIGsNCiAgMzE4LjUwMDAgNjQwLjUwMDAgbQ0KICAzMTguNTAwMCA2MzEuNTAwMCBM DQogIDMxOS4wMDAwIDYzMS41MDAwIEwNCiAgMzE4LjUwMDAgNjMyLjAwMDAgTA0KICAzMTgu MjUwMCA2MzAuNzUwMCBMDQogIDMxOC4yNTAwIDYzMC43NTAwIEwNCiAgMzE4LjAwMDAgNjI5 LjUwMDAgTA0KICAzMTguMDAwMCA2MjkuNTAwMCBMDQogIDMxNy41MDAwIDYyOC4yNTAwIEwN CiAgMzE3LjUwMDAgNjI4LjI1MDAgTA0KICAzMTYuNTAwMCA2MjcuMjUwMCBMDQogIDMxNi43 NTAwIDYyNy41MDAwIEwNCiAgMzE1Ljc1MDAgNjI2LjUwMDAgTA0KICAzMTUuNzUwMCA2MjYu NzUwMCBMDQogIDMxNC41MDAwIDYyNi4wMDAwIEwNCiAgMzE0LjUwMDAgNjI2LjAwMDAgTA0K ICAzMTMuMjUwMCA2MjUuNzUwMCBMDQogIDMxMy4yNTAwIDYyNS43NTAwIEwNCiAgMzEyLjAw MDAgNjI1LjUwMDAgTA0KICAzMTIuMDAwMCA2MjUuNTAwMCBMDQogIDMwMy41MDAwIDYyNS41 MDAwIEwNCiAgMzAzLjUwMDAgNjI0LjUwMDAgTA0KICAzMTIuMDAwMCA2MjQuNTAwMCBMDQog IDMxMy41MDAwIDYyNC43NTAwIEwNCiAgMzE1LjAwMDAgNjI1LjI1MDAgTA0KICAzMTYuMjUw MCA2MjUuNzUwMCBMDQogIDMxNy4yNTAwIDYyNi43NTAwIEwNCiAgMzE4LjI1MDAgNjI3Ljc1 MDAgTA0KICAzMTguNzUwMCA2MjkuMDAwMCBMDQogIDMxOS4yNTAwIDYzMC41MDAwIEwNCiAg MzE5LjUwMDAgNjMyLjUwMDAgTA0KICAzMTkuMDAwMCA2MzIuNTAwMCBMDQogIDMxOS41MDAw IDYzMi4wMDAwIEwNCiAgMzE5LjUwMDAgNjQwLjUwMDAgTA0KICAzMTguNTAwMCA2NDAuNTAw MCBMDQpGDQpVDQp1DQogIDAuMDAwIDAuMDAwIDAuMDAwIDEuMDAwIGsNCiAgMzE1Ljc1MDAg NjQxLjAwMDAgbQ0KICAzMTguMjUwMCA2NDUuMjUwMCBMDQogIDMxOC4yNTAwIDY0NS4yNTAw IEwNCiAgMzIwLjc1MDAgNjQxLjAwMDAgTA0KICAzMjAuNzUwMCA2NDEuMDAwMCBMDQogIDMx NS43NTAwIDY0MS4wMDAwIEwNCiAgMzE1Ljc1MDAgNjQxLjAwMDAgTA0KICAzMTUuNzUwMCA2 NDEuMDAwMCBMDQpCDQpVDQp1DQogIDAuMDAwIDAuMDAwIDAuMDAwIDEuMDAwIGsNCiAgMzI0 LjAwMDAgNjM3LjUwMDAgbQ0KICAzMjguNTAwMCA2MzUuMjUwMCBMDQogIDMyOC41MDAwIDYz NS4yNTAwIEwNCiAgMzI0LjAwMDAgNjMyLjc1MDAgTA0KICAzMjQuMDAwMCA2MzIuNzUwMCBM DQogIDMyNC4wMDAwIDYzNy41MDAwIEwNCiAgMzI0LjAwMDAgNjM3LjUwMDAgTA0KICAzMjQu MDAwMCA2MzcuNTAwMCBMDQpCDQpVDQp1DQogIDAuMDAwIDAuMDAwIDAuMDAwIDEuMDAwIGsN CiAgMzAzLjc1MDAgNjI3LjUwMDAgbQ0KICAyOTkuNTAwMCA2MjUuMjUwMCBMDQogIDI5OS41 MDAwIDYyNS4yNTAwIEwNCiAgMzAzLjc1MDAgNjIyLjc1MDAgTA0KICAzMDMuNzUwMCA2MjIu NzUwMCBMDQogIDMwMy43NTAwIDYyNy41MDAwIEwNCiAgMzAzLjc1MDAgNjI3LjUwMDAgTA0K ICAzMDMuNzUwMCA2MjcuNTAwMCBMDQpCDQpVDQp1DQogIDAuMDAwIDAuMDAwIDAuMDAwIDEu MDAwIGsNCiAgMzA2LjUwMDAgNjIwLjI1MDAgbQ0KICAzMDkuMDAwMCA2MTYuMDAwMCBMDQog IDMwOS4wMDAwIDYxNi4wMDAwIEwNCiAgMzExLjI1MDAgNjIwLjI1MDAgTA0KICAzMTEuMjUw MCA2MjAuMjUwMCBMDQogIDMwNi41MDAwIDYyMC4yNTAwIEwNCiAgMzA2LjUwMDAgNjIwLjI1 MDAgTA0KICAzMDYuNTAwMCA2MjAuMjUwMCBMDQpCDQpVDQowIFRvDQoxIDAgMCAxIDI5Ni43 NSA2MDIuMjUgMCBUcA0KVFANCi9fSGVsdmV0aWNhIDYuMDAwMCBUZg0KMC4wMDAwIFRjDQog MCBUcg0KICAwLjAwMCAwLjAwMCAwLjAwMCAxLjAwMCBLDQogIDAuMDAwIDAuMDAwIDAuMDAw IDEuMDAwIGsNCihFZGdlIFJvdXRlclxyKSBUeA0KVE8NCjAgVG8NCjEgMCAwIDEgNDcuNSA2 NTYuNSAwIFRwDQpUUA0KL19IZWx2ZXRpY2EgNC43NTAwIFRmDQowLjAwMDAgVGMNCiAwIFRy DQogIDAuMDAwIDAuMDAwIDAuMDAwIDEuMDAwIGsNCihDb3JyZXNwb25kZW50IE5vZGVccikg VHgNClRPDQp1DQogIDAuMDAwIDAuMDAwIDAuMDAwIDAuODcxIGsNCiAgMC4wMDAgMC4wMDAg MC4wMDAgMC44NzEgSw0KICA0ODYuNzUwMCA1NzQuNTAwMCBtDQogIDQ4OS4yNTAwIDU3OC43 NTAwIEwNCiAgNDg0LjUwMDAgNTc4Ljc1MDAgTA0KICA0ODYuNzUwMCA1NzQuNTAwMCBMDQpC DQpVDQp1DQogIDAuMDAwIDAuMDAwIDAuMDAwIDAuODcxIGsNCiAgNDc1LjUwMDAgNTgwLjAw MDAgbQ0KICA0NzguMDAwMCA1ODQuMjUwMCBMDQogIDQ3My4wMDAwIDU4NC4yNTAwIEwNCiAg NDc1LjUwMDAgNTgwLjAwMDAgTA0KQg0KVQ0KdQ0KICAwLjAwMCAwLjAwMCAwLjAwMCAwLjg3 MSBrDQogIDgyLjAwMDAgNjY5LjI1MDAgbQ0KICA4NS4wMDAwIDY2NS4yNTAwIEwNCiAgODYu NzUwMCA2NjkuNzUwMCBMDQogIDgyLjAwMDAgNjY5LjI1MDAgTA0KQg0KVQ0KJSVQYWdlVHJh aWxlcg0KZ3NhdmUgYW5ub3RhdGVwYWdlIGdyZXN0b3JlIHNob3dwYWdlDQolJVRyYWlsZXIN CkFkb2JlX0lsbHVzdHJhdG9yX0FJMyAvdGVybWluYXRlIGdldCBleGVjDQpBZG9iZV90eXBv Z3JhcGh5X0FJMyAvdGVybWluYXRlIGdldCBleGVjDQpBZG9iZV9jdXN0b21jb2xvciAvdGVy bWluYXRlIGdldCBleGVjDQpBZG9iZV9jc2hvdyAvdGVybWluYXRlIGdldCBleGVjDQpBZG9i ZV9wYWNrZWRhcnJheSAvdGVybWluYXRlIGdldCBleGVjDQolJUVPRg0KSUkqAAgAAAAMAP4A BAABAAAAAAAAAAABAwABAAAAAQIAAAEBAwABAAAAAgIAAAIBAwABAAAAAQAAAAMBAwABAAAA AQAAAAYBAwABAAAAAQAAABEBBAABAAAArgAAABUBAwABAAAAAQAAABYBBAABAAAAAgIAABcB BAABAAAAgoIAABoBBQABAAAAngAAABsBBQABAAAApgAAAAAAAABIAAAAAQAAAEgAAAABAAAA //////////////////////////////////////////////////////////////////////// /////////////4D////////////////////////////////////w8P////////////////// ////////////////////////////gP////////////////////////////////////////// //////////////////////////////////////////+A//////////////////////////// ///////+//73/////////////////////////////////////////////4D///////////// //////////////////////n//H////////////////////////////////////////////// gP//////////////////////////////////5//4fn////////////////////////////// //////////////+A///////////////////////////////////P//A/P/////////////// /////////////////////////////4D//////////////////////////////////5///v+f ////////////////////////////////////////////gP////////////////////////// ////////v//+/8////////////////////////////////////////////+A//////////// //////////////////////////7x7/////////////////////////////////////////// /4D//////////////////////////////////3//wAAv//////////////////////////// ////////////////gP////////////////////////////////////5+8Pf///////////// //////////////////////////////+A//////////////////////////////////7//f7z 9////////////////////////////////////////////4D///////////////////////// ///////////9/v/3////////////////////////////////////////////gP////////// ///////////////////////+//v9//f///////////////////////////////////////// //+A//////////////////////////////////7+e/3/9/////////////////////////// /////////////////4D///////////////////////////////////h74//3//////////// ////////////////////////////////gP//////////////////////////////////cHv/ /+////////////////////////////////////////////+A//////////////////////// ///////////8e///7////////////////////////////////////////////4D///////// /////////////////////////797/gAP//////////////////////////////////////// ////gP//////////////////////////////////n+B5/5////////////////////////// //////////////////+A///////////////////////////////////v8Mf/L/////////// /////////////////////////////////4D////////////////////////////////////w P/53////////////////////////////////////////////gP////////////////////// /////////////eP///v///////////////////////////////////////////+A//////// ///////////////////////////+H//nwD////////////////////////////////////// /////4D///////////////////////////////////Dj/D+dn/////////////////////// ////////////////////gP//////////////////////////////////j////72f//////// //////////////////////////////////+A//////////////////////////////////x/ ////v5///////////////////////////////////////////4D///////////////////// ////////////w/////+fn///////////////////////////////////////////gP////// /////////////////////////rQrzr/v78Af//////////////////////////////////// //////+A///////////////////////////////+ACBWAEgP29////////////////////// /////////////////////4D///////////////////////////////4AKBKCSC/f3/////// ////////////////////////////////////gP//////////////////////////////+P// ///5/9/v//////////////////////////////////////////+A//////////////////// ///////////H////////3+///////////////////////////////////////////4D///// /////////////////////////D/////////v7/////////////////////////////////// ////////gP/////////////////////////////j/////////+/v//////////////////// //////////////////////+A/////////////////////////////x//////////7+////// /////////////////////////////////////4D////////////////////////////4//// ///////v9///////////////////////////////////////////gP////////////////// /////////4f///////////f3//////////////////////////////////////////+A//// ///////////////////////8f///////////9/f///////////////////////////////// /////////4D//////////////////////////+P////////////39/////////////////// ////////////////////////gP/////////////////////////+H/////////////f7//// //////////////////////////////////////+A//////////////////////////H///// ////////9/v//////////////////////////////////////////4D///////////////// ////////j//////////////7+///////////////////////////////////////////gP// //////////////////////h///////////////v7//////////////////////////////// //////////+A////////////////////////x///////////////+/v///////////////// /////////////////////////4D///////////////////////4////////////////7/f// ////////////////////////////////////////gP//////////////////////4f////// //////////v9//////////////////////////////////////////+A//////////////// //////8f/////////////////f3//////////////////////////////////////////4D/ ////////////////////+P/////////////////9/f////////////////////////////// ////////////gP/////////////////////H//////////////////3+//////////////// //////////////////////////+A/////////////////////D///////////////////f7/ /////////////////////////////////////////4D////////////////////j//////// ///////////9/v//////////////////////////////////////////gP////////////// /////x////////////////////7+//////////////////////////////////////////+A ///////////////////w/////////////////////v7///////////////////////////// /////////////4D//////////////////4/////////////////////+/3////////////// ////////////////////////////gP/////////////////8f/////////////////////7/ f/////////////////////////////////////////+A/////////////////8P///////// /////////////v9//////////////////////////////////////////4D///////////// ///+P///////////////////////f3////////////////////////////////////////// gP////////////////H///////////////////////9/f/////////////////////////// //////////////+A////////////////D////////////////////////3+///////////// /////////////////////////////4D///////////////j///////////////////////// f7//////////////////////////////////////////gP//////////////x/////////// //////////////+/v/////////////////////////////////////////+A//////////// //w//////////////////////////7+///////////////////////////////////////// /4D/////////////4///////////////////////////v9////////////////////////// ////////////////gP////////////8f//////////////////////////+/3/////////// //////////////////////////////+A////////////+P////////////////////////// /7/f/////////////////////////////////////////4D///////////+H//////////// ////////////////39//////////////////////////////////////////gP////////// /H/////////////////////////////f3/////////////////////////////////////// //+A///////////j/////////////////////////////9/v//////////////////////// /////////////////4D//////////h//////////////////////////////3+////////// ////////////////////////////////gP/////////x//////////////////////////// ///f7/////////////////////////////////////////+A/////////4////////////// /////////////////+/v/////////////////////////////////////////4D////////4 f///////////////////////////////7/f//////////////1VVVV////6qqqqv////1VVV V///gP///////8f////////////////////////////////v9/////////////////////// //////////////////+A//gAAAP+P////////////////////////////////+/3//////// /////////////////////////////////4D/8////eH///////////////////////////// ////7/f/////////////////////////////////////////AP/3///9H/////////////// ///////////////////39///////////////////////+AAAH//wAAAf//AAAD+A//f///z/ //////////////////////////////////f7//////////////7////////7///f//f//9// 9///v4D/9////f//////////////////////////////////9/v///////////////////// //v//9//9///3//3//+/gP/3///8D//////////////////////////////////3+/////// ////////////////+///3//3///f//f//7+A//f///wAf/////////////////////////// //////f7///////////////////////7///f//f//9//9///vwD/9////B+A//////////// ////////////////////+/3//////////////v////////v//9//9///3//3//+/gP/3///9 v/8B///////////////////////////////7/f//////////////////////+///3//3///f //f//7+A//P///n///4D//////////////////////////////v9//////////////////// ///7///f//f//9//9///v4D/+AAAA/////wP////////////////////////////+/3///// //////////////////v//9//8///n//3//+/AP////////////Af//////////////////// ///////9/f//////////////////////+AAAP//4AAA///AAAH+A467rqr///////+A///// //////////////////////3+//////////////7//////////j/////+f/////x//4DgKCqg v////////8B//////////////////////////f7////////////////////////+P/////5/ /////H//gP///////////////4D////////////////////////9/v////////////////// //////4//////n/////8f/+A/////////////////wH///////////////////////3+//// //////8Af////////////j/////+f/////x//wD//////////////////gP///////////// /////////v9///////+AAP+f/v/////////+P/////5//////H//gP////////////////// /Af////////////////////+/3///////n///8/+//////////4//////n/////8f/+A//// ////////////////+A////////////////////7/f////8Ac////5////////////j/////+ f/////x//4D/////////////////////8B///////////////////v4eP///H+AOP//3//// w8f////+P/////5//////H//AP//////////////////////4H//////////////////e7// //5//mQ///////9//n////4//////n/////8f/8A////////////////////////gP////// //////////9fv7///v/+Er//9/7/+//3/////j/////+f/////x//4D///////////////// ////////Af///////////////j/fH3/8//56P//3///P/+Pn///+P/////5//////H//gP// ///////////////////////+A//////////////8v+8Pn8H//////+A//5//4fv///4///// /n/////8f/+A///////////////////////////8B/////////////nf8gfvP////////5// P//A/P///j/////+f/////x//wD////////////////////////////4D///////////8+/8 v/Z/////////z/5///f+///+P/////5//////H//gP/////////////////////////////w H//////////39/8/+v/////////+/v//9/9///4AAAH//n/////8f/+A//////////////// ///////////////gP////////+/7/4Y5/////////+/9///wAAAAAD///v/+f/////x//4D/ ///////////////////////////////Af///////3/zwAA3/////////gAAAAAABv//+P/// P/5//////H//AP////////////////////////////////+B///////f/x++BP///AAAAAB8 e//798e///4////f/n/////8f/8A//////////////////////////////////4D/////9// h774AAAD//////6b//f339///gAAB+/+f/////x//4D///////////////////////////// //////wH////3/94v/7P/////////+P/7/AAAAAAAAAAAAAAAAAAAH//gP////////////// //////////////////////gP///f/38f/p////////+AAAAAB//AAAAAAAAAAAAAAAAAf/+A //////////////////////////////////////Af/9/Pf2A+f//8AAAAAH/z+e/v/9////// 5vf////H/////wD//////////////////////////////////////+Af3w94/8AAAAP///// //vh7z//v+AAAAPm9////8f/////gP///////////////////////////////////////+Ac D3///P/////////+84AAAAAAH///+eX3////x/////+A//////////////////////////// /////////////+APf//5//////8AAAAAAe///3/////95ff////H/////4D///////////// ////////////////////////////98AP//ngAAAAAP///+757/////////3l9////8f///// gP/////////////////////////////////////////z+BAAAB//////////3n8D//7///// /eX3////x/////8A//////////////////////////////////////////n8P//vP/////// //w/P4f//P/////95ff////H/////4D///////////////////////////////////////// /v4//5/AD///////8f/fx//7//////3l9////8f/////gP////////////////////////// ////////////////v3//f//v///////n///v/+///////eX3////x/////+A//////////// /////////////////////////////////////+///////8/////////////95ff////H//// /wD///////////////////////////////////////////h/D///3///////n///A8H///// //3l9////8f/////gP/////////////////////////////////////////////////v/+f+ D/4+/////////////eX3////x/////+A//////////////////////////////////////// //////////f/w/zgEP/////////////95ff////H/////4D///////////////////////// ////////////////////////+P88Qf////////////////3l9////8f/////gP////////// ///////////////////////////////3/Pv/////AP8f////+tOff////////eX3////x/// //8A//////////////////////////////////////////IEiH////////////74AJEP//// ///95ff////H/////4D/////////////////////////////////////////9gUAf/////// /////vkAoA////////gAF///gAAD////gP////////////////////////////////////// ////n///////////////////////////+AAX//9///v///+A//////////////////////// ///////////////////////////////////////////////4AJf//3///f///wD///////// //////////////////////////////////////////////////////////////jll///f//9 ////gP/////////////////////////////////////////////////////////+//////// /////eX3//9///3///+A//////////////////////////////////////////////////// ///////////////////95ff//3///f///4D///////////////////////////////////// //////////////////////////////////3l9///f//9////gP////////////////////// /////////////////////////////////////////////////eX3//9///3///8A//////// ///////////////////////////////////////////////////////////////95ff//3// +f///4D//////////////////////////////////////////////////////////v////// /////4AAA///AAAD////gP////////////////////////////////////////////////// ////////////////////Pf3x//////////+A//////////////////////////////////// //////////////////////////////////99/fX//////////wD///////////////////// /////////////////////////////////////////////////3399f//////////AP////// ///////////////////////////////////////////////////+////////////YH/1//// //////+A//////////////////////////////////////////////////////////////// //////9w/u3//////////4D///////////////////////////////////////////////// /////////////////////3j/Hf//////////gP////////////////////////////////// ////////////////////////////////////ff+9//////////8A//////////////////// //////////////////////////////////////////////////8//g3//////////4D///// /////////////////////////////////////////////////////v///////////4AAAf// ////////gP////////////////////////////////////////////////////////////// //////////8f//////////+A//////////////////////////////////////////////// //////////////////////7car///////////4D///////////////////////////////// /////////////////////////////////////kBgv///////////AP////////////////// ///////////////////////////////////////+//////////////////////////+A//// //////////////////////////////////////////////////////////////////////// /////////4D///////////////////////////////////////////////////////////// ////////////////////////gP////////////////////////////////////////////// /////////////+qqqqv////1VVVVf////qqqqr+A//////////////////////////////// /////////////////////////////////////////////////////4D///////////////// ////////////////////////////////////////////////////////////////////gP// ////////////////////////////////////////////////////////////////m7vl3/v/ //////////+A//////////////////////////////////////////////////////////// //////+QAGQVCf///////////4D///////////////////////////////////////////// /////////////////////4kgaBhJ////////////gP////////////////////////////// ////////////////////////////////////qABsGwr///////////+A//////////////// /////////////////////////////////////////////////////////////////////4D/ //////////////////////////////////////////////////////////////////////// ////////////gP////////////////////////////////////////////////////////// //////////////////////////+A//////////////////////////////////////////// /////////////////////////////////////////4D///////////////////////////// ////////////////////////////////////////////////////////gP////////////// //////////////////////////////////////////////////////////////////////+A //////////////////////////////////////////////////////////////////////// /////////////4D///////////////////////////////////////////////////////// ////////////////////////////gP////////////////////////////////////////// //////////////////////////////////////////+A//////////////////////////// /////////////////////////////////////////////////////////4D///////////// //////////////////////////////////////////////////////////////////////// gP////////////////////////////////////////////////////////////////////// //////////////+A//////////////////////////////////////////////////////// /////////////////////////////4D///////////////////////////////////////// ////////////////////////////////////////////gP////////////////////////// //////////////////////////////////////////////////////////+A//////////// //////////////////////////////////////////////////////////////////////// /4D///////////////////////////////////////////////////////////////////// ////////////////gP////////////////////////////////////////////////////// //////////////////////////////+A//////////////////////////////////////// /////////////////////////////////////////////4D///////////////////////// ////////////////////////////////////////////////////////////gP////////// //////////////////////////////////////////////////////////////////////// //+A//////////////////////////////////////////////////////////////////// /////////////////4D///////////////////////////////////////////////////// ////////////////////////////////gP////////////////////////////////////// //////////////////////////////////////////////+A//////////////////////// /////////////////////////////////////////////////////////////4D///////// //////////////////////////////////////////////////////////////////////// ////gP////////////////////////////////////////////////////////////////// //////////////////+A//////////////////////////////////////////////////// /////////////////////////////////4D///////////////////////////////////// ////////////////////////////////////////////////gP////////////////////// //////////////////////////////////////////////////////////////+A//////// //////////////////////////////////////////////////////////////////////// /////4D///////////////////////////////////////////////////////////////// ////////////////////gP////////////////////////////////////////////////// //////////////////////////////////+A//////////////////////////////////// /////////////////////////////////////////////////4D///////////////////// ////////////////////////////////////////////////////////////////gP////// //////////////////////////////////////////////////////////////////////// //////+A//////////////////////////////////////////////////////////////// /////////////////////4D///////////////////////////////////////////////// ////////////////////////////////////gP////////////////////////////////// //////////////////////////////////////////////////+A//////////////////// /////////////////////////////////////////////////////////////////4D///// //////////////////////////////////////////////////////////////////////// ////////gP////////////////////////////////////////////////////////////// //////////////////////+A//////////////////////////////////////////////// /////////////////////////////////////4D///////////////////////////////// ////////////////////////////////////////////////////gP////////////////// //////////////////////////////////////////////////////////////////+A//// //////////////////////////////////////////////////////////////////////// /////////4D///////////////////////////////////////////////////////////// ////////////////////////gP////////////////////////////////////////////// //////////////////////////////////////+A//////////////////////////////// /////////////////////////////////////////////////////4D///////////////// ////////////////////////////////////////////////////////////////////gP// //////////////////////////////////////////////////////////////////////// //////////+A//////////////////////////////////////////////////////////// /////////////////////////4D///////////////////////////////////////////// ////////////////////////////////////////gP////////////////////////////// //////////////////////////////////////////////////////+A//////////////// /////////////////////////////////////////////////////////////////////4D/ //////////////////////////////////////////////////////////////////////// ////////////gP////////////////////////////////////////////////////////// //////////////////////////+A//////////////////////////////////////////// /////////////////////////////////////////4D///////////////////////////// ////////////////////////////////////////////////////////gP////////////// //////////////////////////////////////////////////////////////////////+A //////////////////////////////////////////////////////////////////////// /////////////4D///////////////////////////////////////////////////////// ////////////////////////////gP////////////////////////////////////////// //////////////////////////////////////////+A//////////////////////////// /////////////////////////////////////////////////////////4D///////////// //////////////////////////////////////////////////////////////////////// gP////////////////////////////////////////////////////////////////////// //////////////+A//////////////////////////////////////////////////////// /////////////////////////////4D///////////////////////////////////////// ////////////////////////////////////////////gP////////////////////////// //////////////////////////////////////////////////////////+A//////////// //////////////////////////////////////////////////////////////////////// /4D///////////////////////////////////////////////////////////////////// ////////////////gP////////////////////////////////////////////////////// //////////////////////////////+A//////////////////////////////////////// /////////////////////////////////////////////4D///////////////////////// ////////////////////////////////////////////////////////////gP////////// //////////////////////////////////////////////////////////////////////// //+A//////////////////////////////////////////////////////////////////// /////////////////4D///////////////////////////////////////////////////// ////////////////////////////////gP////////////////////////////////////// //////////////////////////////////////////////+A//////////////////////// /////////////////////////////////////////////////////////////4D///////// //////////////////////////////////////////////////////////////////////// ////gP////////////////////////////////////////////////////////////////// //////////////////+A//////////////////////////////////////////////////// /////////////////////////////////4D///////////////////////////////////// ////////////////////////////////////////////////gP////////////////////// //////////////////////////////////////////////////////////////+A//////// //////////////////////////////////////////////////////////////////////// /////4D///////////////////////////////////////////////////////////////// ////////////////////gP////////////////////////////////////////////////// //////////////////////////////////+A//////////////////////////////////// /////////////////////////////////////////////////4D///////////////////// ////////////////////////////////////////////////////////////////gP////// //////////////////////////////////////////////////////////////////////// //////+A//////////////////////////////////////////////////////////////// /////////////////////4D///////////////////////////////////////////////// ////////////////////////////////////gP////////////////////////////////// //////////////////////////////////////////////////+A//////////////////// /////////////////////////////////////////////////////////////////4D///// //////////////////////////////////////////////////////////////////////// ////////gP////////////////////////////////////////////////////////////// //////////////////////+A//////////////////////////////////////////////// /////////////////////////////////////4D///////////////////////////////// ////////////////////////////////////////////////////gP////////////////// //////////////////////////////////////////////////////////////////+A//// //////////////////////////////////////////////////////////////////////// /////////4D///////////////////////////////////////////////////////////// ////////////////////////gP////////////////////////////////////////////// //////////////////////////////////////+A//////////////////////////////// /////////////////////////////////////////////////////4D///////////////// ////////////////////////////////////////////////////////////////////gP// //////////////////////////////////////////////////////////////////////// //////////+A//////////////////////////////////////////////////////////// /////////////////////////4D///////////////////////////////////////////// ////////////////////////////////////////gP////////////////////////////// //////////////////////////////////////////////////////+A//////////////// /////////////////////////////////////////////////////////////////////4D/ //////////////////////////////////////////////////////////////////////// ////////////gP////////////////////////////////////////////////////////// //////////////////////////+A//////////////////////////////////////////// /////////////////////////////////////////4D///////////////////////////// ////////////////////////////////////////////////////////gP////////////// //////////////////////////////////////////////////////////////////////+A //////////////////////////////////////////////////////////////////////// /////////////4D///////////////////////////////////////////////////////// ////////////////////////////gP////////////////////////////////////////// //////////////////////////////////////////+A//////////////////////////// /////////////////////////////////////////////////////////4D///////////// //////////////////////////////////////////////////////////////////////// gP////////////////////////////////////////////////////////////////////// //////////////+A//////////////////////////////////////////////////////// /////////////////////////////4D///////////////////////////////////////// ////////////////////////////////////////////gP////////////////////////// //////////////////////////////////////////////////////////+A//////////// //////////////////////////////////////////////////////////////////////// /4D///////////////////////////////////////////////////////////////////// ////////////////gP////////////////////////////////////////////////////// //////////////////////////////+A//////////////////////////////////////// /////////////////////////////////////////////4D///////////////////////// ////////////////////////////////////////////////////////////gP////////// //////////////////////////////////////////////////////////////////////// //+A//////////////////////////////////////////////////////////////////// /////////////////4D///////////////////////////////////////////////////// ////////////////////////////////gP////////////////////////////////////// //////////////////////////////////////////////+A//////////////////////// /////////////////////////////////////////////////////////////4D///////// //////////////////////////////////////////////////////////////////////// ////gP////////////////////////////////////////////////////////////////// //////////////////+A//////////////////////////////////////////////////// /////////////////////////////////4D///////////////////////////////////// ////////////////////////////////////////////////gP////////////////////// //////////////////////////////////////////////////////////////+A//////// //////////////////////////////////////////////////////////////////////// /////4D///////////////////////////////////////////////////////////////// ////////////////////gP////////////////////////////////////////////////// //////////////////////////////////+A//////////////////////////////////// /////////////////////////////////////////////////4D///////////////////// ////////////////////////////////////////////////////////////////gP////// //////////////////////////////////////////////////////////////////////// //////+A//////////////////////////////////////////////////////////////// /////////////////////4D///////////////////////////////////////////////// ////////////////////////////////////gP////////////////////////////////// //////////////////////////////////////////////////+A//////////////////// /////////////////////////////////////////////////////////////////4D///// //////////////////////////////////////////////////////////////////////// ////////gP////////////////////////////////////////////////////////////// //////////////////////+A//////////////////////////////////////////////// /////////////////////////////////////4D///////////////////////////////// ////////////////////////////////////////////////////gP////////////////// //////////////////////////////////////////////////////////////////+A//// //////////////////////////////////////////////////////////////////////// /////////4D///////////////////////////////////////////////////////////// ////////////////////////gP////////////////////////////////////////////// //////////////////////////////////////+A//////////////////////////////// /////////////////////////////////////////////////////4D///////////////// ////////////////////////////////////////////////////////////////////gP// //////////////////////////////////////////////////////////////////////// //////////+A//////////////////////////////////////////////////////////// /////////////////////////4D///////////////////////////////////////////// ////////////////////////////////////////gP////////////////////////////// //////////////////////////////////////////////////////+A//////////////// /////////////////////////////////////////////////////////////////////4D/ //////////////////////////////////////////////////////////////////////// ////////////gP////////////////////////////////////////////////////////// //////////////////////////+A//////////////////////////////////////////// /////////////////////////////////////////4D///////////////////////////// ////////////////////////////////////////////////////////gP////////////// //////////////////////////////////////////////////////////////////////+A //////////////////////////////////////////////////////////////////////// /////////////4D///////////////////////////////////////////////////////// ////////////////////////////gP////////////////////////////////////////// //////////////////////////////////////////+A//////////////////////////// /////////////////////////////////////////////////////////4D///////////// //////////////////////////////////////////////////////////////////////// gP////////////////////////////////////////////////////////////////////// //////////////+A//////////////////////////////////////////////////////// /////////////////////////////4D///////////////////////////////////////// ////////////////////////////////////////////gP////////////////////////// //////////////////////////////////////////////////////////+A//////////// //////////////////////////////////////////////////////////////////////// /4D///////////////////////////////////////////////////////////////////// ////////////////gP////////////////////////////////////////////////////// //////////////////////////////+A//////////////////////////////////////// /////////////////////////////////////////////4D///////////////////////// ////////////////////////////////////////////////////////////gP////////// //////////////////////////////////////////////////////////////////////// //+A//////////////////////////////////////////////////////////////////// /////////////////4D///////////////////////////////////////////////////// ////////////////////////////////gP////////////////////////////////////// //////////////////////////////////////////////+A//////////////////////// /////////////////////////////////////////////////////////////4D///////// //////////////////////////////////////////////////////////////////////// ////gP////////////////////////////////////////////////////////////////// //////////////////+A//////////////////////////////////////////////////// /////////////////////////////////4D///////////////////////////////////// ////////////////////////////////////////////////gP////////////////////// //////////////////////////////////////////////////////////////+A//////// //////////////////////////////////////////////////////////////////////// /////4D///////////////////////////////////////////////////////////////// ////////////////////gP////////////////////////////////////////////////// //////////////////////////////////+A//////////////////////////////////// /////////////////////////////////////////////////4D///////////////////// ////////////////////////////////////////////////////////////////gP////// //////////////////////////////////////////////////////////////////////// //////+A//////////////////////////////////////////////////////////////// /////////////////////4D///////////////////////////////////////////////// ////////////////////////////////////gP////////////////////////////////// /w/h//////////////////////////////////////////////+A//////////////////// ///////////////+f/5//////////////////////////////////////////////4D///// //////////////////////////////P/98////////////////////////////////////// ////////gP//////////////////////////////////7//j5/////////////////////// //////////////////////+A//////////////////////////////////+//+H///////// /////////////////////////////////////4D///////////////////////////////// /3//wP7/////////////////////////////////////////////gP////////////////// ///////////////+///3/3////////////////////////////////////////////+A//// //////////////////////////////3///fP//////////////////////////////////// /////////4D//////////////////////////////////f//98O///////////////////// ////////////////////////gP/////////////////////////////////9//x3wb////// //////////////////////////////////////+A//////////////////////////////// //v/+/fH/////////////////////////////////////////////4D///////////////// ////////////////+//399/f////////////////////////////////////////////gP// ///////////////////////////////7/+/3/9////////////////////////////////// //////////+A//////////////////////////////////v/7/f/3/////////////////// /////////////////////////4D/////////////////////////////////+/nv7//f//// ////////////////////////////////////////gP////////////////////////////// ///74AA///////////////////////////////////////////////+A//////////////// //////////////////2B7///v////////////////////////////////////////////4D/ /////////////////////////////////fHv/g////////////////////////////////// ////////////gP/////////////////////////////////+/+/B8X////////////////// //////////////////////////+A//////////////////////////////////9/gj/+f/// /////////////////////////////////////////4D///////////////////////////// /////7/B//2/////////////////////////////////////////////gP////////////// ////////////////////3wf//9////////////////////////////////////////////+A ///////////////////////////////////w7//Pg/////////////////////////////// /////////////4D//////////////////////////////////8B//n8s//////////////// ////////////////////////////gP/////////////////////////////////8P8AH/u7/ //////////////////////////////////////////+A//////////////////////////// /////+P////89n///////////////////////////////////////////4D///////////// ////////////////////H/////z+//////////////////////////////////////////// gP////////////////////////////////j//////Hx///////////////////////////// //////////////+A///////////////////////////////1h151/39+AX////////////// /////////////////////////////4D///////////////////////////////ABArACQH7/ f///////////////////////////////////////////gP////////////////////////// ////4gFAlBJBfv9///////////////////////////////////////////+A//////////// //////////////////8f/////8/+/3////////////////////////////////////////// /4D/////////////////////////////8P////////9/v/////////////////////////// ////////////////gP////////////////////////////+P/////////3+///////////// //////////////////////////////+A/////////////////////////////H////////// f7///////////////////////////////////////////4D///////////////////////// ///j//////////9/v///////////////////////////////////////////gP////////// /////////////////h///////////3/f//////////////////////////////////////// //+A///////////////////////////x////////////v9////////////////////////// /////////////////4D//////////////////////////4////////////+/3/////////// ////////////////////////////////gP/////////////////////////8f/////////// /7/f//////////////////////////////////////////+A//////////////////////// /8P/////////////v9///////////////////////////////////////////4D///////// ///////////////+P//////////////f7/////////////////////////////////////// ////gP////////////////////////H//////////////9/v//////////////////////// //////////////////+A////////////////////////j///////////////3+////////// /////////////////////////////////4D///////////////////////h///////////// ///f7///////////////////////////////////////////gP////////////////////// x////////////////+/v//////////////////////////////////////////+A//////// //////////////4/////////////////7/f///////////////////////////////////// /////4D/////////////////////4f/////////////////v9/////////////////////// ////////////////////gP////////////////////8f/////////////////+/3//////// //////////////////////////////////+A////////////////////+P////////////// ////7/f//////////////////////////////////////////4D////////////////////H ///////////////////3+///////////////////////////////////////////gP////// /////////////D////////////////////f7//////////////////////////////////// //////+A///////////////////j////////////////////9/v///////////////////// /////////////////////4D//////////////////x/////////////////////3+/////// ////////////////////////////////////gP/////////////////4//////////////// //////v7//////////////////////////////////////////+A/////////////////4f/ ////////////////////+/3//////////////////////////////////////////4D///// ///////////8f//////////////////////7/f////////////////////////////////// ////////gP///////////////+P///////////////////////v9//////////////////// //////////////////////+A////////////////H///////////////////////+/3///// /////////////////////////////////////4D///////////////D///////////////// ///////9/f//////////////////////////////////////////gP//////////////j/// //////////////////////3+//////////////////////////////////////////+A//// //////////x//////////////////////////f7///////////////////////////////// /////////4D/////////////4//////////////////////////9/v////////////////// ////////////////////////gP////////////4f//////////////////////////7+//// //////////////////////////////////////+A////////////8f////////////////// /////////v7//////////////////////////////////////////4D///////////+P//// ///////////////////////+/3//////////////////////////////////////////gP// /////////H////////////////////////////7/f/////////////////////////////// //////////+A///////////D/////////////////////////////39///////////////// /////////////////////////4D//////////j//////////////////////////////f3// ////////////////////////////////////////gP/////////x//////////////////// //////////9/v/////////////////////////////////////////+A/////////4////// /////////////////////////3+//////////////////////////////////////////4D/ ///////4f///////////////////////////////f7//////////////+qqqr////9VVVVf/ ///qqqqq////gP///////8f///////////////////////////////+/v/////////////// //////////////////////////2A//AAAB/+P////////////////////////////////7+/ //////////////v//////////////////////////4D/z///z/H///////////////////// ////////////v9//////////////////////////////////////////gP/f///vD/////// //////////////////////////+/3///////////////////////4AAA///gAAH//8AAAf+A /9///+j//////////////////////////////////9/f///////////////////////P//5/ /8///v//n//8/YD/3///5///////////////////////////////////39////////////// +////////9///3//3//+//+///79gP/f///sf//////////////////////////////////f 3//////////////7////////3///f//f//7//7///v+A/9///+B///////////////////// /////////////9/v///////////////////////f//9//9///v//v//+/4D/3///6AD///// ////////////////////////////3+///////////////////////9///3//3//+//+///7/ gP/f///u/wD////////////////////////////////v7///////////////////////3/// f//f//7//7///v2A/9///+///wD//////////////////////////////+/v//////////// //v////////f//9//9///v//v//+/4D/z///z////wH///////////////////////////// 7/f//////////////////////9///3//3//+//+///7/gP/wAAAf/////gf///////////// ///////////////v9///////////////////////z//+f//P//z//5///P+A//////////// +A////////////////////////////f3///////////////////////wAAD//+AAAf//4AAB /4COu66q////////8D//////////////////////////9/f////////////////////////5 //////H/////8//9gICgqoL/////////wP/////////////////////////39/////////// ///7//////////n/////8f/////z//+A////////////////Af////////////////////// //f7////////////////////////+f/////x//////P//4D////////////////+A/////// ////////////////+/v///////+D8AH////////////5//////H/////8///gP////////// ///////8A//////////////////////7+////////HwH/n////////////n/////8f/////z //2A///////////////////8B/////////////////////v7///////x////P/v///////// +f/////x//////P//4D////////////////////4D///////////////////+/0P///+gAA9 //+/////4f/////5//////H/////8///gP/////////////////////wH/////////////// ///94fw///z/+ZH//7////z/5/////n/////8f/////z//+A///////////////////////g H/////////////////3e/4//+//4SP//n///4//8////+f/////x//////P//4D///////// ///////////////gP////////////////P9+8//3//nv//+///+f/95////5//////H///// 8//9gP/////////////////////////Af//////////////5f7x8/+f//////7/7/3//j9// //n/////8f/////z//+A//////////////////////////+Af/////////////9/2H9+D/// ////gP////8P7///+f/////x//////P//4D///////////////////////////+A//////// /////7/gP7j////////+f////gf3///5//////H/////8///gP////////////////////// //////8D////////////z/L/2/////////8/////3/v///n/////8f/////z//2A//////// //////////////////////wH/////////7/3/PAAAAAAAAAAAAAAf//eff//+f/////x//// //P//4D///////////////////////////////gf////////P/v+ADf/////////v++//94e ///5//////H/////8///gP///////////////////////////////+B///////9//Z7gB/// //////+H78AT3gb///n/////8f/////z//+A/////////////////////////////////4D/ /////3/+/vBj//////////Dv38/eHv//+f/////x//////P//4D///////////////////// /////////////wD///////0+82R//////////n/fgAAAAAAAAAAH//H/////8//9gP////// /////////////////////////////wD///7//cL8Zn/////////7n9+/3/+AAAAAAAAAAAAA AAAD//+A/////////////////////////////////////wD//3/7/AeU///////////PIH// /oAAAAAAAAAAAAAAAAP//4D//////////////////////////////////////wP/fnv58AAA AAAAAAAAAADPfz/+//////+e/////x//////gP////////////////////////////////// /////AN4AAf/8///////////zwAA//7//////57/////H/////2A//////////////////// /////////////////////AB78AAAAAAAAAAAAAAAD3///v//////n3////8f/////4D///// ////////////////////////////////////vgBkf+f//////////7fHf//9//////+ff/// /x//////gP//////////////////////////////////////////+4N/1///////////P/gA AAAAAAAH/5+/////H/////+A///////////////////////////////////////////gTn+z //////////x/4A//9/////j/n7////8f/////4D///////////////////////////////// //////////DgAAAAAAAAAAAAAAAeH//v/////3+fv////x/////9gP////////////////// ///////////////////////7+P/+/wA///////+L/z8f/5//////n5+/////H/////+A//// //////////////////////////////////////z9//P//3///////7//n7/+P//////fn7// //8f/////4D//////////////////////////////////////////x//h///f///////f//j //P//////++fv////x//////gP//////////////////////////////////////////+AD/ //9///////z///8AH///////75+/////H/////2A//////////////////////////////// /////////////////7//n/gf8fv////////////vn7////8f/////YD///////////////// ////////////////////////////////z/5P58AH+////////////++fv////x//////gP// ///////////////////////////////////////////////h4fAP////////////////75+/ ////H/////+A/////////////////////////////////////////7/n3/////wf///////r Tn3////////vn7////8f/////4D/////////////////////////////////////////kCRD /////////////+ACRD///////+AAP////x/////9gP////////////////////////////// //////////+wKAP////////////75AKAP///////4AA///wAAA////+A//////////////// //////////////////////////z////////////////////////////kAD///f//7////4D/ /////////////////////////////////////////////////////////////////////+QA P//9///v////gP////////////////////////////////////////////////////////// ////////////75+///3//+////+A//////////////////////////////////////////// ///////////////////////////vn7///f//7////YD///////////////////////////// ////////////////////////////+////////////++fv//9///v////gP////////////// ////////////////////////////////////////////////////////75+///3//+////+A ///////////////////////////////////////////////////////////////////////v n7///f//7////4D///////////////////////////////////////////////////////// /////////////++fv//9///v///9gP////////////////////////////////////////// ///////////////7///////////8AAAP//wAAA////+A//////////////////////////// //////////////////////////////////////////3v/7f//////////4D///////////// /////////////////////////////////////////////////////////e//t/////////// gP/////////////////////////////////////////////////////////////////////9 7/+3//////////+A//////////////////////////////////////////////////////// //////////////3v/7f//////////YD///////////////////////////////////////// ////////////////+////////////YH/t///////////gP////////////////////////// ///////////////////////////////////////////9w/4H//////////+A//////////// //////////////////////////////////////////////////////////3H/xf///////// /4D///////////////////////////////////////////////////////////////////// /e//B//////////9gP////////////////////////////////////////////////////// ///7///////////+AAAP//////////+A//////////////////////////////////////// /////////////////////////////////////////////4D///////////////////////// ////////////////////////////////////////////9uNV////////////gP////////// ///////////////////////////////////////////////////////////yAwX///////// //+A//////////////////////////////////////////////////////////////////// /////////////////YD///////////////////////////////////////////////////// ////+///////////////////////////gP////////////////////////////////////// //////////////////////9VVVVX////6qqqq/////VVVVWA//////////////////////// /////////////////////////////////////////////////////////////4D///////// //////////////////////////////////////////////////////////////////////// ////gP////////////////////////////////////////////////////////////////// //////////////////+A//////////////////////////////////////////////////// //////////////5u75d/7////////////4D///////////////////////////////////// /////////////////////////////kABkFQn////////////gP////////////////////// ///////////////////////////////////////////+JIGgYSf///////////+A//////// //////////////////////////////////////////////////////////6gAbBsK/////// /////4D///////////////////////////////////////////////////////////////// ////////////////////gP////////////////////////////////////////////////// //////////////////////////////////+A//////////////////////////////////// /////////////////////////////////////////////////4A= --------------CB49B1CED950610369ECF7C6-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 9 12:05: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 MAA05965 for ; Mon, 9 Oct 2000 12:05:21 -0400 (EDT) Received: from standards (47.234.32.16:2682) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0070@standards.nortelnetworks.com>; Mon, 9 Oct 2000 11:45:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 38216 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 9 Oct 2000 11:45:58 -0400 Received: from harrier.prod.itd.earthlink.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA003E@standards.nortelnetworks.com>; Mon, 9 Oct 2000 11:35:57 -0400 Received: from mail.earthlink.net (1Cust43.tnt2.panama-city.fl.da.uu.net [63.25.165.43]) by harrier.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with SMTP id IAA05903; Mon, 9 Oct 2000 08:50:12 -0700 (PDT) Received: from cashgrants3@bigfoot.com by cashgrants30@bigfoot.com (8.8.5/8.6.5) with SMTP id GAA06371 for ; Mon, 09 Oct 2000 07:09:20 -0600 (EST) Message-ID: <> Date: Mon, 9 Oct 2000 07:09:20 EST Reply-To: cashgrants3@BIGFOOT.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: cashgrants3@BIGFOOT.COM Subject: [MOBILE-IP] CASH FREE GRANTS X-To: cashgrats30@bigfoot.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Dear Consumer Every day millions of dollars are given away!!! Our Government spends billions of tax dollars on government grants. Do you know that private foundations, trust and corporations are required to give away a portion of their assets. It does'nt matter, where you live, your employment status, or if you are broke, retired or living on a fixed income. There may be a grant for you! CASHING IN ON FREE GOVERNMENT GRANTS FOR PERSONAL NEEDS, BUSINESS, MEDICAL BILLS, EDUCATION, DEBTS AND MORE.... How would you like to get $125.000.00 to start your business? You can use the money to expand, finance equipment, pay salaries, rent and more. How about $8,000.00 spending money for your personal needs such as car payments, rent, clothing, credit card debts, home repair, groceries. Do you need $12,000.00 for education for yourself, or your children? You can get money for private, secondary and primary school. There are grants for undergraduate, graduate, professional and foreign studies and more. THE BEST PART IS THAT YOU NEVER HAVE TO PAY IT BACK! IT IS INTEREST FREE AND NON TAXABLE! NO CREDIT CHECKS, COSIGNERS, SECURITY DEPOSITS OR COLLATERAL REQUIRED. There are no strict requirements to meet. If you have a genuine need, the money can be yours. IT'S TIME FOR YOU TO TAKE ADVANTAGE OF THIS COUNTRY'S BEST KEPT SECRET! We have made the process easy. We have researched and compiled a manual that will help you find a grant. OUR MANUAL" HOW TO OBTAIN FREE CASH GRANTS" will provide you with 45 pages of grant sources. We list the foundations name, address, phone number, contact person and the type of grant they issue. QUESTIONS AND ANSWERS Q: Is obtaining a cash grant legal? A: It is 100% legal and yours for the asking. The Government wants you to take advantage of their grant program and our manual will show you how. Q: How do I get paid? A: The Government agency will send you an acceptance letter with your award amount. Q: Will bad credit interfere with obtaining a free cash grant? A: NO, In fact grants are not based on your credit. It is not a loan, even the unemployed receive grants. Q: What is the average grant amount awarded? A: $1,000.00 to 10,000.00 is average, but it depends on what the grant will be used for. Businesses that benefit the communities have been awarded $100,000 to millions in grant money. Q: If I obtain your publication manual, am I guaranteed to find a grant? A: The US Federal Trade Commission warns consumers that no one can guarantee you a grant, you must apply to the grant offering foundations, corporations etc.. They will review your request and supply your grant if your needs meet the requirements of the grant. We do provide you with a 60 day money back guarantee! This will give you time to apply for some grants and get a response. ACT IN THE NEXT 14 DAYS AND RECEIVE THE "HOW TO OBTAIN FREE CASH GRANT'S "MANUAL AND A FREE BONUS, "HOW TO WRITE A WINNING GRANT PROPOSAL". This guide will list the secrets on getting your grant proposal accepted. RECEIVE ALL THIS FOR THE UNBELIEVABLE LOW PRICE OF $24.95! ACT NOW!! ORDER INFORMATION SIMPLY SEND $24.95, CHECK, MONEY ORDER, OR CREDIT CARD INFORMATION INCLUDE YOUR NAME, ACCOUNT NUMBER, EXPIRATION DATE, ADDRESS AND PHONE NUMBER. TO: INFORMATION PLUS PO BOX 9889 PANAMA CITY BEACH, FL 32417 This mailing is done by an independent marketing co. We apologize if this message has reached you in error. Save the Planet, Save the Trees! Advertise via E mail. No wasted paper! Delete with one simple keystroke! Less refuse in our Dumps! This is the new way of the new millennium! To be removed francis@dcemail.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 9 13:12:28 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 NAA07030 for ; Mon, 9 Oct 2000 13:12:28 -0400 (EDT) Received: from standards (47.234.32.16:2682) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA01AE@standards.nortelnetworks.com>; Mon, 9 Oct 2000 12:55:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 38712 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 9 Oct 2000 12:55:48 -0400 Received: from ebene.inrialpes.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA01AD@standards.nortelnetworks.com>; Mon, 9 Oct 2000 12:55:47 -0400 Received: from galibier.inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id TAA22672 for ; Mon, 9 Oct 2000 19:10:29 +0200 (MET DST) Received: from inrialpes.fr (localhost [127.0.0.1]) by galibier.inrialpes.fr (8.8.7/8.8.5) with ESMTP id RAA17457; Mon, 9 Oct 2000 17:57:09 +0200 (MET DST) X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <39E1DACE.B5DBE8E7@zeus.nt.op.dlr.de> Content-Type: text/plain; charset=iso-8859-1 Message-ID: <39E1EAD4.E985AB65@inrialpes.fr> Date: Mon, 9 Oct 2000 17:57:08 +0200 Reply-To: Thierry.Ernst@INRIALPES.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Thierry Ernst Organization: INRIA Rhone-Alpes Subject: Re: [MOBILE-IP] A practical question... X-cc: mberio@libero.it, berioli@ZEUS.NT.OP.DLR.DE To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA07030 Matteo Berioli wrote: > PROBLEM: Let' s assume we have a Mobile Router, to which a Mobile Host > attaches. We know how the matters work with IPv4 and Mobile IP (see > RFC 2002 par: 4.5 page 61-62). The problem is here that we have a > double re-direction of each packet directed to the Mobile Host. As a > matter of fact, each packet has to pass through the Home Agent of the > Mobile Host and then through the Home Agent of the Mobile Router. > Let's assume, now, that the mobile network is an IPv6 network. In IPv6 > could be this double re-direction avoided? Hi Matteo, I have also been doing some thinking about mobile networks. This issue has not really been addressed nor even raised though there are many interesting problems to be dealt with. At the time being, Mobile IPv6 does not support mobile networks at all. The Home Agent of the Mobile Router is unable to redirect packets sent to a node attached to the Mobile Router (call it MNN - Mobile Network Node), and no optimal routing is possible between the CN and the MNN. See my Internet Draft for the problem description on the IETF web site or on my web page: http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network > 1° possibility > A pool of IPv6 addresses is assigned to the Mobile Router when it > desires to connect to the Internet; so the Mobile Router can assigned > an its own Care-of Address to each Mobile Host asking for one. This > allows the Mobile Host to inform by itself its Correspondent Nodes and > its Home Agent of this new Care-of Address, and this avoids the double > re-direction... You need a protocol to enquire and distribute the care-of address between the Mobile Host and the Mobile Router. > 2° possibility > A single IPv4 address is assigned to the Mobile Router as its Care-of > Address, because, for example, the Edge Router to which the Mobile > Router attaches doesn't support IPv6. Now the problem comes! Are you dealing with Mobile IPv4 or with Mobile IPv6 ? > It could be solved in this way (I wonder if it is possible and > realistic...): > when a Mobile Host attaches to the Mobile Router, it asks to the DHCP > server, which is in the Mobile Router, for a Care-of Address, and > sends its Home Address to it; The DHCP server is not necessarily on the Mobile Router. The Mobile Network may be composed of several routers (i.e. subnets). What if the Mobile Host does not attach directly to the Mobile Router ? > the Mobile Router could use Stateful Address Autoconfiguration > (setting M=1 in the Router Advertisement packets), and it could oblige > all the hosts in the mobile network, to acquire the same Care-of > Address, that is the one it got from the Edge Router!! > So all the hosts, both fixed and mobile hosts, share one Care-of > Address; but they don't care about this, because the Mobile Router set > M=1 in the Router Advertisement packets, so avoiding Stateless Address > Autoconfiguration and Duplicate Address Detection. > So each host on the mobile network can inform by itself its > Correspondent Nodes and its Home Agent of this new Care-of Address. As a result, all hosts have to take active part in the mobility management of the mobile router. I don't find this solution reasonable. My solution is that all the mobility management is done by the Mobile Router (MR) ; the MR advertises its CoA together with its prefix asking all CNs of nodes located in the mobile network to use the MR's CoA when they want to send a packet holding a destination address matching the prefix of the MR. > Now when a packet arrives to the Mobile Router, obviously it will be > encapsulated in an IPv4 packet (see figure in the attachment), so > first of all the Mobile Router has to decapsulate it. > Then if the packet comes from a Correspondent Node it will have, as > Destination IP Address, the Care-of Address of the Mobile Router and > in the Routing Header it will have the Home Address of the Mobile Host > that is on the mobile network, and with which the Correspondent Node > is communicating. > The Mobile Router knows the Home Addresses of the Mobile Hosts it has > in charge and knows to which link-layer addresses they are related; so > the Mobile Router has to recognize this address in the Routing Header > and it has to forward the packet directly in the local network to the > Mobile Host. Same comment as before, if the MN does not attach directly to the MR. Cheers, Thierry. -- * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) * http://www.inrialpes.fr/planete/people/ernst/Welcome.html From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 9 15:14: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 PAA08746 for ; Mon, 9 Oct 2000 15:14:49 -0400 (EDT) Received: from standards (47.234.32.16:4540) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA02B0@standards.nortelnetworks.com>; Mon, 9 Oct 2000 14:57:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39056 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 9 Oct 2000 14:57:48 -0400 Received: from qhars002.nortel.com (47.101.112.102:41371) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA02AE@standards.nortelnetworks.com>; Mon, 9 Oct 2000 14:57:47 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Mon, 9 Oct 2000 20:11:47 +0100 Received: from zrchs148 by smtprch1.nortel.com; Mon, 9 Oct 2000 14:11:21 -0500 Received: from zrchb200.us.nortel.com (actually zrchb200) by zrchs148; Mon, 9 Oct 2000 14:03:25 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 9 Oct 2000 14:11:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03224.AE5A2A50" Message-ID: <36FA02BD7083D411BC9E0000F8073E438CEEC8@crchy271.us.nortel.com> Date: Mon, 9 Oct 2000 14:11:09 -0500 Reply-To: Glenn Morrow Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Glenn Morrow Subject: Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup port in IPv6"draft] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM ------_=_NextPart_001_01C03224.AE5A2A50 Content-type: text/plain; charset="us-ascii" > In fact, I wish it were not required even when the mobile > node is away from home. In the future, if my fantasy comes > true and ingress filtering is abolished, there will no longer > be such a need for this restriction. If an access router has a mobile node associated with it, then it should probably be smart enough to allow the mobile to use it's home address(es) as the destination. In my opinion in an optimal environment ingress filtering should only be done on the first hop at an access router, NAS, etc.. I have a similar fantasy but still believe the source filtering may be needed only on the first hop from the source. It may be that a rogue routing network may actually turn off 1st hop ingress filtering and thus allow DoS attacks to originate from it. To handle this, perhaps a method should be pursued of dynamically turning the filtering temporarily on and off, once the origin edge network is discovered. I.e. routing protocol work? The problems with this are: 1> mobility is nuked during the origin location process. 2> if authentication of the signaling for turning on the filtering is not done then this signaling could be used as a new form of mobile DoS attack. The positive argument to item (1)'s temporary "problems" is that DoS attacks may nuke a good portion of both mobile and non-mobile traffic anyway. The positive argument to (2) is simply to do strong authentication on these requests - no brainer. On the bright side, I believe some recent work on filters between autonomous systems have been published in the form of drafts for BGP4. The applicability of this function for mobility in turning source address ingress filtering on and off are not explicitly detailed in the drafts, however. People on the list and perhaps in the ipng wg might want to take a look at and guage an opinion for these drafts. http://search.ietf.org/internet-drafts/draft-ietf-idr-route-filter-00.txt http://search.ietf.org/internet-drafts/draft-chen-bgp-route-filter-01.txt http://search.ietf.org/internet-drafts/draft-chen-bgp-prefix-orf-00.txt Perhaps the authors might wish to elaborate on some of the practical uses; in particular - support for mobility without the use of COA as source address. I feel that this "find the bozos, shut them down and then let things return to normal" solution would be far better than forcing ingress filtering to be used all the time and everywhere. I suspect that this could be accomplished rather quickly only denying service for a very short time. If the DoS attacks are not that bad, perhaps the search and destroy procedures could be done at off hours. > What do you think about the "not at all swap" proposal? > Or have I missed something else important here? > Regards, > Charlie P. gm> No you haven't - thanks for bringing it up in a positive light. I'm very interested in other proposals for solutions as well. Let's get rid of the need for tunneling. Including the home address option is just another form of minimal tunneling in my book. The AH question is only one such issue that tunneling affects. Thank You, Glenn ------_=_NextPart_001_01C03224.AE5A2A50 Content-type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of = "MobilitySupport in IPv6"draft]

> In fact, I wish it were not required even when = the mobile
> node is away from home.  In the future, if = my fantasy comes
> true and ingress filtering is abolished, there = will no longer
> be such a need for this restriction.


If an access router = has a mobile node associated with it, then it should probably be smart = enough to allow the mobile to use it's home address(es) as the = destination.

In my opinion in an = optimal environment ingress filtering should only be done on the first = hop at an access router, NAS, etc..

I have a similar = fantasy but still believe the source filtering may be needed only on = the first hop from the source.

It may be that a = rogue routing network may actually turn off 1st hop ingress filtering = and thus allow DoS attacks to originate from it. To handle this, = perhaps a method should be pursued of dynamically turning the filtering = temporarily on and off, once the origin edge network is discovered. = I.e. routing protocol work?

The problems with = this are:

1> mobility is = nuked during the origin location process.
2> if = authentication of the signaling for turning on the filtering is not = done then
  this = signaling could be used as a new form of mobile DoS attack.

The positive = argument to item (1)'s temporary "problems" is that DoS = attacks may nuke a good portion of both mobile and non-mobile traffic = anyway.

The positive = argument to (2) is simply to do strong authentication on these requests = - no brainer.

On the bright side, = I believe some recent work on filters between autonomous systems have = been published in the form of drafts for BGP4. The applicability of = this function for mobility in turning source address ingress filtering = on and off are not explicitly detailed in the drafts, however.  =

People on the list = and perhaps in the ipng wg might want to take a look at and guage an = opinion for these drafts.

http://search.ietf.org/internet-drafts/draft-ietf-idr-= route-filter-00.txt
http://search.ietf.org/internet-drafts/draft-chen-bgp-= route-filter-01.txt
http://search.ietf.org/internet-drafts/draft-chen-bgp-= prefix-orf-00.txt

Perhaps the authors = might wish to elaborate on some of the practical uses; in particular - = support for mobility without the use of COA as source = address.

I feel that this = "find the bozos, shut them down and then let things return to = normal" solution would be far better than forcing ingress = filtering to be used all the time and everywhere.

I suspect that this = could be accomplished rather quickly only denying service for a very = short time.

If the DoS attacks = are not that bad, perhaps the search and destroy procedures could be = done at off hours.



    > What do you think about the "not at all = swap" proposal?
    > Or have I missed something else important = here?

    > Regards,
    > Charlie P.

gm> No  you = haven't - thanks for bringing it up in a positive light.

I'm very interested = in other proposals for solutions as well. Let's get rid of the need for = tunneling. Including the home address option is just another form of = minimal tunneling in my book. The AH question is only one such issue = that tunneling affects.

Thank You,

Glenn




------_=_NextPart_001_01C03224.AE5A2A50-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 9 17:18: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 RAA10071 for ; Mon, 9 Oct 2000 17:18:56 -0400 (EDT) Received: from standards (47.234.32.16:3063) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA040E@standards.nortelnetworks.com>; Mon, 9 Oct 2000 16:59:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39526 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 9 Oct 2000 16:59:20 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA040C@standards.nortelnetworks.com>; Mon, 9 Oct 2000 16:59:19 -0400 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Mon Oct 9 17:12:58 EDT 2000 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Mon Oct 9 17:12:58 EDT 2000 Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP id 675565701F; Mon, 9 Oct 2000 16:12:57 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <5F05C89FB2F8D211B6430008C791912703EA81B2@esealnt190> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-ID: <20001009211257.675565701F@king.research.bell-labs.com> Date: Mon, 9 Oct 2000 16:12:57 -0500 Reply-To: Pete McCann Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Pete McCann Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac hes X-To: "Karim El-Malki (ERA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <5F05C89FB2F8D211B6430008C791912703EA81B2@esealnt190> Content-Transfer-Encoding: 7bit "Karim El-Malki (ERA)" (KE) writes: > 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. KE> I am aware of this and am not disagreeing. KE> My point is that the registration can be done before the Mobile KE> gets the L2 message informing it to handoff. Thus we require KE> interworking between L2 and L3 on the network-side (which is KE> needed anyway) such that L3 registration can occur at the same KE> time as L2 signalling and such that the L2 handoff message is KE> sent after the L3 registration. As I wrote in my reply to Pete, KE> this is what is summed up in point 2) of the list of differences KE> sent out. Let's consider the interval between the two events: (a) The network gets an indication (power measurements, whatever) that a handoff to a new point of attachment is necessary. (b) The handoff is physically performed and the MS tunes to the new BS. Now, in today's cellular systems, the interval between these two events (let's refer to it as [a,b]) is hard and well-specified. [a,b] is so small that the *very next message* sent after (a) is the "do handoff" message sent to the MS. The MS then *immediately* tunes to the new BS and the handoff is completed or the call is dropped, in case the MS cannot tune to the new BS. The hard deadline comes from the fact that the signal strength to the current BS is rapidly degrading, presumably because the MS is moving away. Now, the Proactive draft assumes that we will live with this state of affairs for the forseeable future, and allows the L2 messages (the power indications leading to (a), and the handoff command implementing (b)) to run unchanged. The Fast Handoff draft proposes to insert 2 messages into the interval [a,b]: 1. A Mobile IP Agent Advertisement, from the target FA. (How the source FA gets this advertisement is left unspecified and may add additional time to the handoff). 2. A Mobile IP Registration Request originating from the MN's Mobile IP Client implementation. Now whether there is time for these messages to run over-the-air is debatable; it may be the case that for some handoffs, the signal strength is not degrading quickly enough to cause the disconnection to happen prior to the Registration Request. But that is not really my point. My point is that the Registration Request is generated by a non-real-time piece of L3 software on the MN, which might actually be running on a laptop computer connected to a phone. So, in addition to the two over-the-air messages, you need to allow time for: 1a. The Agent advertisement to be sent from the phone to the laptop. 1b. The interrupt handler on the laptop to run. 1c. The agent advertisement to be queued in the laptop's kernel. 1d. The bottom half scheduler to get a chance to run and dequeue the message, dispatching it to the IP stack. 1e. The generation of a Mobile IP Registration Request. 1f. The transmission of such a request to the phone. Now, I am not prepared to put a real-time deadline on how long it will take 1a through 1f to run, especially 1d if there is a lot of other activity on the laptop that is causing bottom half scheduling to be delayed. I do not want to put this unpredictable non-realtime delay on the critical path before a handoff can take place. If the opportunity for the handoff is missed the call is dropped and we have a noticeable interruption in service. If you only want MIP clients to run in tightly-integrated real-time embedded systems (such as phones manufactured by a particular vendor) then your point of view makes sense. Personally I would not like to see these real-time requirements imposed on the MIP client; as I said I think it runs counter to the Internet design philosophy which has historically put soft, but not hard, real-time constraints on IP stack implementations. -Pete From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 9 19:10: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 TAA11011 for ; Mon, 9 Oct 2000 19:10:12 -0400 (EDT) Received: from standards (47.234.32.16:3851) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA04E8@standards.nortelnetworks.com>; Mon, 9 Oct 2000 18:53:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39821 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 9 Oct 2000 18:53:33 -0400 Received: from catarina.usc.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA04E6@standards.nortelnetworks.com>; Mon, 9 Oct 2000 18:53:32 -0400 Received: from localhost (meeta@localhost) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA89913 for ; Mon, 9 Oct 2000 16:08:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Mon, 9 Oct 2000 16:08:15 -0700 Reply-To: Meeta Sharma Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Meeta Sharma Subject: [MOBILE-IP] Registration Reply To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi all, I was looking into mobile ip(rfc 2002) for one of my projects. I had a question: What happens when the registration reply(i) from foreign agent to mobile node is delayed? It can happen that the timer at the mobile node expires and that the mobile node sends another request(i+1)..but then it gets a reply(i) would it accept it or reject it? Also, what if Foreign agent sees that it had sent a reply for (i) and now is getting a request(i+1) then would it discard it or send the reply back again? without going to the home agent? I am a little confused and maybe the answers would help me in my model. Thanks, Regards, Meeta From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 9 19:17: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 TAA11087 for ; Mon, 9 Oct 2000 19:17:43 -0400 (EDT) Received: from standards (47.234.32.16:3851) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA052B@standards.nortelnetworks.com>; Mon, 9 Oct 2000 18:59:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39910 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 9 Oct 2000 18:59:05 -0400 Received: from sj-msg-core-2.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0529@standards.nortelnetworks.com>; Mon, 9 Oct 2000 18:59:05 -0400 Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA07283; Mon, 9 Oct 2000 16:13:49 -0700 (PDT) X-Sender: fred@flipper X-Mailer: QUALCOMM Windows Eudora Version 5.0 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.0.0.25.2.20001009160104.01e68b80@flipper> Date: Mon, 9 Oct 2000 16:13:03 -0700 Reply-To: Fred Baker Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fred Baker Subject: Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup port in IPv6"draft] X-To: Glenn Morrow To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <36FA02BD7083D411BC9E0000F8073E438CEEC8@crchy271.us.nortel. com> At 02:11 PM 10/9/00 -0500, Glenn Morrow wrote: >I feel that this "find the bozos, shut them down and then let things >return to normal" solution would be far better than forcing ingress >filtering to be used all the time and everywhere. how do you detect the bozos? I think the argument for using ingress filtering all the time is that it does indeed detect most bozos. By the way, the most usual implementation of ingress filtering goes rather beyond what the RFC actually says - it uses a reverse path forwarding check. This has its own dangers, however, related to asymmetric routing. Ingress filtering says "if you are among a few known bad things, I will detect you", meaning that on every packet I have to apply a number of rules. RPF says "if it would be reasonable for me to forward to you along this path, I will let you forward via me", which happens to be a single lookup way to apply a much stronger rule set. But asymmetric routing may make it possible only for you to forward via me while I consider quite another route to be my most reasonable route to you. Hence, ingress filtering is usually only done at the edge-network-to-ISP interface; ISP-ISP interfaces get eaten by asymmetric routing pretty badly. I personally would favor a form of ingress filtering that ensures that only addresses that may be found on a first-hop-router interface get used as sources - in short, that the MAC Source Address and the IP Source Address indeed match at the first hop, or on a dial line, that the Source IP Address is the one that was assigned to the device dialing in. This would detect a lot of bozo addressing. From an operational perspective, though, unless we made this somehow mandatory to turn on and had laws that imposed stiff fines for turning it off, operators could never trust it; they would need to do their own RPF checks anyway, as this is the only defense that they could control. And yes, I think they do in fact turn on the RPF check when they think it is appropriate, in many cases, as opposed to leaving it on all the time. Note that if I require the IP Source Address and the MAC Address to match, I just made COA addresses a failure case... This would have to be seen as an acceptable exception. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 9 19:45: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 TAA11359 for ; Mon, 9 Oct 2000 19:45:23 -0400 (EDT) Received: from standards (47.234.32.16:3851) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA05DC@standards.nortelnetworks.com>; Mon, 9 Oct 2000 19:28:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 40142 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 9 Oct 2000 19:28:41 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:52810) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA05DA@standards.nortelnetworks.com>; Mon, 9 Oct 2000 19:28:39 -0400 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 JAA10324; Tue, 10 Oct 2000 09:40:34 +1000 (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 KAA07720; Tue, 10 Oct 2000 10:42:51 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Oct 2000 10:43:00 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0324A.A693D9D0" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB34B@eaubrnt018.epa.ericsson.se> Date: Tue, 10 Oct 2000 10:42:57 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] A practical question... X-To: "Thierry.Ernst@INRIALPES.FR" 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_01C0324A.A693D9D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Thierry, I believe your solution is perfect for one case : The devices connected to the MR do not have a MIPv6 implementation.=20 Some people might argue that if you do not have a MIPv6 implementation then you should not be mobile. But that is also debatable I think. If the devices have MIPv6 in them (ie. MN's) then they can manage their = own mobility. There is a chapter on this in the HMIPv6 draft. In this = case=20 the MR advertises itself as a MAP upon entering a foreign network. As a result the MN's attached to it would register with the HA with an=20 alt-CoA which is the MR's (MAP) address.=20 It would be good to get your comments on this solution.=20 Cheers, Hesham > -----Original Message----- > From: Thierry Ernst [SMTP:thierry.ernst@INRIALPES.FR] > Sent: Tuesday, 10 October 2000 2:57 > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] A practical question... >=20 > Matteo Berioli wrote: > > PROBLEM: Let' s assume we have a Mobile Router, to which a Mobile = Host > > attaches. We know how the matters work with IPv4 and Mobile IP (see > > RFC 2002 par: 4.5 page 61-62). The problem is here that we have a > > double re-direction of each packet directed to the Mobile Host. As = a > > matter of fact, each packet has to pass through the Home Agent of = the > > Mobile Host and then through the Home Agent of the Mobile Router. > > Let's assume, now, that the mobile network is an IPv6 network. In = IPv6 > > could be this double re-direction avoided? >=20 > Hi Matteo, >=20 > I have also been doing some thinking about mobile networks. This = issue > has not really been addressed nor even raised though there are many > interesting problems to be dealt with. =20 >=20 > At the time being, Mobile IPv6 does not support mobile networks at = all. =20 > The Home Agent of the Mobile Router is unable to redirect packets = sent > to a node attached to the Mobile Router (call it MNN - Mobile Network > Node), and no optimal routing is possible between the CN and the MNN. = =20 > See my Internet Draft for the problem description on the IETF web = site > or on my web page: > = http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobil= ei > p-v6-network >=20 >=20 > > 1=B0 possibility > > A pool of IPv6 addresses is assigned to the Mobile Router when it > > desires to connect to the Internet; so the Mobile Router can = assigned > > an its own Care-of Address to each Mobile Host asking for one. This > > allows the Mobile Host to inform by itself its Correspondent Nodes = and > > its Home Agent of this new Care-of Address, and this avoids the = double > > re-direction... >=20 > You need a protocol to enquire and distribute the care-of address > between the Mobile Host and the Mobile Router. =20 >=20 > > 2=B0 possibility > > A single IPv4 address is assigned to the Mobile Router as its = Care-of > > Address, because, for example, the Edge Router to which the Mobile > > Router attaches doesn't support IPv6. Now the problem comes! >=20 > Are you dealing with Mobile IPv4 or with Mobile IPv6 ? =20 >=20 > > It could be solved in this way (I wonder if it is possible and > > realistic...): > > when a Mobile Host attaches to the Mobile Router, it asks to the = DHCP > > server, which is in the Mobile Router, for a Care-of Address, and > > sends its Home Address to it; >=20 > The DHCP server is not necessarily on the Mobile Router. The Mobile > Network may be composed of several routers (i.e. subnets). What if = the > Mobile Host does not attach directly to the Mobile Router ? >=20 > > the Mobile Router could use Stateful Address Autoconfiguration > > (setting M=3D1 in the Router Advertisement packets), and it could = oblige > > all the hosts in the mobile network, to acquire the same Care-of > > Address, that is the one it got from the Edge Router!! >=20 > > So all the hosts, both fixed and mobile hosts, share one Care-of > > Address; but they don't care about this, because the Mobile Router = set > > M=3D1 in the Router Advertisement packets, so avoiding Stateless = Address > > Autoconfiguration and Duplicate Address Detection. > > So each host on the mobile network can inform by itself its > > Correspondent Nodes and its Home Agent of this new Care-of Address. >=20 > As a result, all hosts have to take active part in the mobility > management of the mobile router. I don't find this solution > reasonable. My solution is that all the mobility management is done = by > the Mobile Router (MR) ; the MR advertises its CoA together with its > prefix asking all CNs of nodes located in the mobile network to use = the > MR's CoA when they want to send a packet holding a destination = address > matching the prefix of the MR. >=20 > > Now when a packet arrives to the Mobile Router, obviously it will = be > > encapsulated in an IPv4 packet (see figure in the attachment), so > > first of all the Mobile Router has to decapsulate it. > > Then if the packet comes from a Correspondent Node it will have, as > > Destination IP Address, the Care-of Address of the Mobile Router = and > > in the Routing Header it will have the Home Address of the Mobile = Host > > that is on the mobile network, and with which the Correspondent = Node > > is communicating. >=20 > > The Mobile Router knows the Home Addresses of the Mobile Hosts it = has > > in charge and knows to which link-layer addresses they are related; = so > > the Mobile Router has to recognize this address in the Routing = Header > > and it has to forward the packet directly in the local network to = the > > Mobile Host. >=20 > Same comment as before, if the MN does not attach directly to the MR. >=20 >=20 > Cheers, > Thierry. >=20 > -- > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69=20 > * INRIA Rhone-Alpes Projet PLANETE (fax 52 52)=20 > * http://www.inrialpes.fr/planete/people/ernst/Welcome.html ------_=_NextPart_001_01C0324A.A693D9D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] A practical question...

Hi Thierry,

I believe your = solution is perfect for one case :
The devices = connected to the MR do not have a MIPv6 implementation.
Some people might = argue that if you do not have a MIPv6 implementation
then you should not = be mobile. But that is also debatable I think.

If the devices have = MIPv6 in them (ie. MN's) then they can manage their
own mobility. There = is a chapter on this in the HMIPv6 draft. In this case
the MR advertises = itself as a MAP upon entering a foreign network.
As a result the = MN's attached to it would register with the HA with an
alt-CoA which is = the MR's (MAP) address.

It would be good to = get your comments on this solution.

Cheers,
Hesham

    -----Original Message-----
    From:   Thierry Ernst = [SMTP:thierry.ernst@INRIALPES.FR]
    Sent:   Tuesday, 10 October 2000 2:57
    To:     MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: [MOBILE-IP] A practical = question...

    Matteo Berioli wrote:
    > PROBLEM: Let' s assume we have a = Mobile Router, to which a Mobile Host
    > attaches. We know how the = matters work with IPv4 and Mobile IP (see
    > RFC 2002 par: 4.5 page 61-62). = The problem is here that we have a
    > double re-direction of each = packet directed to the Mobile Host. As a
    > matter of fact, each packet has = to pass through the Home Agent of the
    > Mobile Host and then through the = Home Agent of the Mobile Router.
    > Let's assume, now, that the = mobile network is an IPv6 network. In IPv6
    > could be this double = re-direction avoided?

    Hi Matteo,

    I have also been doing some thinking = about mobile networks.  This issue
    has not really been addressed nor = even raised though there are many
    interesting problems to be dealt = with.  

    At the time being, Mobile IPv6 does = not support mobile networks at all. 
    The Home Agent of the Mobile Router = is unable to redirect packets sent
    to a node attached to the Mobile = Router (call it MNN - Mobile Network
    Node), and no optimal routing is = possible between the CN and the MNN.  
    See my Internet Draft for the problem = description on the IETF web site
    or on my web page:
    http://www.inrialpes.fr/planete/people/ernst/Documents= /draft-ernst-mobileip-v6-network


    > 1=B0 possibility
    > A pool of IPv6 addresses is = assigned to the Mobile Router when it
    > desires to connect to the = Internet; so the Mobile Router can assigned
    > an its own Care-of Address to = each Mobile Host asking for one. This
    > allows the Mobile Host to inform = by itself its Correspondent Nodes and
    > its Home Agent of this new = Care-of Address, and this avoids the double
    > re-direction...

    You need a protocol to enquire and = distribute the care-of address
    between the Mobile Host and the = Mobile Router.  

    > 2=B0 possibility
    > A single IPv4 address is = assigned to the Mobile Router as its Care-of
    > Address, because, for example, = the Edge Router to which the Mobile
    > Router attaches doesn't support = IPv6. Now the problem comes!

    Are you dealing with Mobile IPv4 or = with Mobile IPv6 ? 

    > It could be solved in this way (I = wonder if it is possible and
    > realistic...):
    > when a Mobile Host attaches to = the Mobile Router, it asks to the DHCP
    > server, which is in the Mobile = Router, for a Care-of Address, and
    > sends its Home Address to = it;

    The DHCP server is not necessarily on = the Mobile Router.   The Mobile
    Network may be composed of several = routers (i.e. subnets).  What if the
    Mobile Host does not attach directly = to the Mobile Router ?

    > the Mobile Router could use = Stateful Address Autoconfiguration
    > (setting M=3D1 in the Router = Advertisement packets), and it could oblige
    > all the hosts in the mobile = network, to acquire the same Care-of
    > Address, that is the one it got = from the Edge Router!!

    > So all the hosts, both fixed and = mobile hosts, share one Care-of
    > Address; but they don't care = about this, because the Mobile Router set
    > M=3D1 in the Router = Advertisement packets, so avoiding Stateless Address
    > Autoconfiguration and Duplicate = Address Detection.
    > So each host on the mobile = network can inform by itself its
    > Correspondent Nodes and its Home = Agent of this new Care-of Address.

    As a result, all hosts have to take = active part in the mobility
    management of the mobile = router.     I don't find this solution
    reasonable.   My solution = is that all the mobility management is done by
    the Mobile Router (MR) ; the MR = advertises its CoA together with its
    prefix asking all CNs of nodes = located in the mobile network to use the
    MR's CoA when they want to send a = packet holding a destination address
    matching the prefix of the MR.

    > Now when a packet arrives to the = Mobile Router, obviously it will be
    > encapsulated in an IPv4 packet = (see figure in the attachment), so
    > first of all the Mobile Router = has to decapsulate it.
    > Then if the packet comes from a = Correspondent Node it will have, as
    > Destination IP Address, the = Care-of Address of the Mobile Router and
    > in the Routing Header it will = have the Home Address of the Mobile Host
    > that is on the mobile network, = and with which the Correspondent Node
    > is communicating.

    > The Mobile Router knows the Home = Addresses of the Mobile Hosts it has
    > in charge and knows to which = link-layer addresses they are related; so
    > the Mobile Router has to = recognize this address in the Routing Header
    > and it has to forward the packet = directly in the local network to the
    > Mobile Host.

    Same comment as before, if the MN does = not attach directly to the MR.


    Cheers,
    Thierry.

    --
    * mailto:Thierry.Ernst@inrialpe= s.fr  Tel +33 (0) 4 = 76 61 52 69
    * INRIA Rhone-Alpes Projet = PLANETE       (fax 52 52)
    * http://www.inrialpes.fr/planete/people/ernst/Welcome.h= tml

------_=_NextPart_001_01C0324A.A693D9D0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 10 06:25: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 GAA00479 for ; Tue, 10 Oct 2000 06:25:22 -0400 (EDT) Received: from standards (47.234.32.16:3305) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA08B6@standards.nortelnetworks.com>; Tue, 10 Oct 2000 6:08:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41116 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 10 Oct 2000 06:08:34 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA08B4@standards.nortelnetworks.com>; Tue, 10 Oct 2000 6:08:34 -0400 Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id e9AANIt13268 for ; Tue, 10 Oct 2000 12:23:18 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Oct 10 12:16:54 2000 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id <42DD612H>; Tue, 10 Oct 2000 12:23:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <5F05C89FB2F8D211B6430008C791912703EA81C2@esealnt190> Date: Tue, 10 Oct 2000 12:04:41 +0200 Reply-To: "Karim El-Malki (ERA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Karim El-Malki (ERA)" Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac hes To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Pete > Now, in today's cellular systems, the interval between these two > events (let's refer to it as [a,b]) is hard and well-specified. [a,b] > is so small that the *very next message* sent after (a) is the "do > handoff" message sent to the MS. The MS then *immediately* tunes to > the new BS and the handoff is completed or the call is dropped, in > case the MS cannot tune to the new BS. The hard deadline comes from > the fact that the signal strength to the current BS is rapidly > degrading, presumably because the MS is moving away. Here is where I don't agree with your basic assumptions. Some systems (CDMA-based) don't have such a hard deadline since there is no strict geographical limit beyond which the MN is unreachable. Some L2 procedures and messages go on between event a and event b. So this doesn't stop us from synchronising L2 and L3 procedures. Also, a BS coverage area is not the same as a MIP FA coverage area and a L2 handoff doesn't imply a L3 handoff. > Now, the Proactive draft assumes that we will live with this state of > affairs for the forseeable future, and allows the L2 messages (the > power indications leading to (a), and the handoff command implementing > (b)) to run unchanged. We don't imply that they will be changed either, but what we are concerned with is the communication/interworking between L2 and L3, while maintaining the RFC2002 approach. > Now whether there is time for these messages to run over-the-air is > debatable; it may be the case that for some handoffs, the signal > strength is not degrading quickly enough to cause the disconnection > to happen prior to the Registration Request. But that is not really > my point. My point is that the Registration Request is generated by > a non-real-time piece of L3 software on the MN, which might actually > be running on a laptop computer connected to a phone. I don't believe we can get away with (or want) such total independence between L2 and L3 in the future wireless systems which the v4 handoffs team was working towards. Do you? Regards, Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 10 06:39: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 GAA00596 for ; Tue, 10 Oct 2000 06:39:16 -0400 (EDT) Received: from standards (47.234.32.16:3305) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0938@standards.nortelnetworks.com>; Tue, 10 Oct 2000 6:22:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41293 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 10 Oct 2000 06:22:25 -0400 Received: from ebene.inrialpes.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0936@standards.nortelnetworks.com>; Tue, 10 Oct 2000 6:22:24 -0400 Received: from galibier.inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id MAA09490; Tue, 10 Oct 2000 12:36:56 +0200 (MET DST) Received: from inrialpes.fr (localhost [127.0.0.1]) by galibier.inrialpes.fr (8.8.7/8.8.5) with ESMTP id MAA18115; Tue, 10 Oct 2000 12:36:55 +0200 (MET DST) X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <4B6BC00CD15FD2119E5F0008C7A419A5089EB34B@eaubrnt018.epa.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39E2F147.6252E490@inrialpes.fr> Date: Tue, 10 Oct 2000 12:36:55 +0200 Reply-To: Thierry.Ernst@INRIALPES.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Thierry Ernst Organization: INRIA Rhone-Alpes Subject: Re: [MOBILE-IP] A practical question... X-cc: "Hesham Soliman (EPA)" , thierry.ernst@crm.mot.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Hesham, See my comments below. > "Hesham Soliman (EPA)" wrote: > > Hi Thierry, > > I believe your solution is perfect for one case : > The devices connected to the MR do not have a MIPv6 implementation. > Some people might argue that if you do not have a MIPv6 implementation > then you should not be mobile. But that is also debatable I think. > If the devices have MIPv6 in them (ie. MN's) then they can manage > their > own mobility. There is a chapter on this in the HMIPv6 draft. In this > case > the MR advertises itself as a MAP upon entering a foreign network. > As a result the MN's attached to it would register with the HA with an > alt-CoA which is the MR's (MAP) address. > > It would be good to get your comments on this solution. As I understand your draft http://ietf.org/internet-drafts/draft-ietf-mobileip-hmipv6-00.txt, the MN enters the mobile network and listens to router advertisements. It gets a LCOA and registers with the MAP, i.e the mobile router MR. It adversites the MAP's address to its HA and its CNs. Fine. How packets get routed from the CN to the MN ? I understand that the MAP's address is the home address of the MR. The MR also gets a care-of address at each of its Access Router. Then, the packets sent from CN to MN is sent to the MAP's address and the routing header contains the home address of the MN. The packet gets routed to the HA of the MR where it is encapulated to the current care-of address of the MR as if the final destination was the MR itself. The final destination is transparent to the HA. The packet is received and decapsulated by MR and the desitnation address is switched with the one contained in the routing header. The packet is then forwarded to the MN. Your proposition therefore works for mobile nodes MNs visiting a mobile network. (However, there is no optimal routing between CN and MN, but this not the present subject of the discussion) What about FIXED nodes located in the mobile network ? This was the topic of my draft http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network. For the same reasons as outlined in my draft, the packet sent from a CN to a FIXED host located in the mobile network can not reach its final destination. Packets are routed to the HA of the MR and then the HA does not know what to do with them. Those enters in a loop until the TTL expires. See the explanation in my draft. As a result, FIXED nodes in the mobile network never see the packets sent from CNs. From what I understand, your solution does address this issue. I agree that your solution is fine for MNs that visit the mobile network, but one shouldn't forget about those FIXED host located in the mobile network. To me, the issue of routing packet from CNs to the FIXED host is more important as this is more likely to happen. Cheers, Thierry. * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) * http://www.inrialpes.fr/planete/people/ernst/Welcome.html From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 10 08:09: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 IAA02274 for ; Tue, 10 Oct 2000 08:09:25 -0400 (EDT) Received: from standards (47.234.32.16:3305) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0A4A@standards.nortelnetworks.com>; Tue, 10 Oct 2000 7:52:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41627 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 10 Oct 2000 07:52:38 -0400 Received: from nishio-mail.ise.eng.osaka-u.ac.jp (thames.ise.eng.osaka-u.ac.jp) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0A42@standards.nortelnetworks.com>; Tue, 10 Oct 2000 7:42:36 -0400 Received: from localhost (yukon.ise.eng.osaka-u.ac.jp [133.1.52.148]) by nishio-mail.ise.eng.osaka-u.ac.jp (8.9.3/3.7W-03/30/00) with ESMTP id UAA12750 for ; Tue, 10 Oct 2000 20:57:10 +0900 (JST) References: <5F05C89FB2F8D211B6430008C791912703EA81C2@esealnt190> X-Mailer: Mew version 1.93b25 on Emacs 19.28 / Mule 2.3 (=?iso-2022-jp?B?GyRCS3ZFJjJWGyhC?=) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 6 Message-ID: <20001010205710C.wooighee@ise.eng.osaka-u.ac.jp> Date: Tue, 10 Oct 2000 20:57:10 +0900 Reply-To: WANG Wooi Ghee Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: WANG Wooi Ghee Subject: [MOBILE-IP] Addressing in ad hoc network To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hai all I would like to know that whether there is any work been done on addressing in Mobile Ad Hoc Network ? ghee From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 10 09:15: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 JAA03419 for ; Tue, 10 Oct 2000 09:15:17 -0400 (EDT) Received: from standards (47.234.32.16:1420) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0B0C@standards.nortelnetworks.com>; Tue, 10 Oct 2000 8:58:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41874 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 10 Oct 2000 08:58:34 -0400 Received: from hub.ecutel.com (ecutel.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0B06@standards.nortelnetworks.com>; Tue, 10 Oct 2000 8:48:34 -0400 Received: from 192.168.50.149 by smtp.ecutel.com Tue, 10 Oct 2000 09:14:40 -0500 Received: from gsm [192.168.50.6] by hub.ecutel.com (SMTPD32-5.05) id AAE13B4F014C; Tue, 10 Oct 2000 09:34:25 -0400 X-Sender: makineni@hub.ecutel.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.5.32.20001010090725.0132b100@hub.ecutel.com> Date: Tue, 10 Oct 2000 09:07:25 -0500 Reply-To: "Gowri S.Makineni" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Gowri S.Makineni" Subject: Re: [MOBILE-IP] Registration Reply X-To: Meeta Sharma To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: At 04:08 PM 10/9/00 -0700, Meeta Sharma wrote: >Hi all, >I was looking into mobile ip(rfc 2002) for one of my projects. I had a >question: >What happens when the registration reply(i) from foreign agent to mobile >node is delayed? It can happen that the timer at the mobile node expires >and that the mobile node sends another request(i+1)..but then it gets a >reply(i) would it accept it or reject it? If the timer expires at the mobile node, it sends another registration request, and discards replies to the previous requests that it sent. >Also, what if Foreign agent sees that it had sent a reply for (i) and now >is getting a request(i+1) then would it discard it or send the reply back >again? without going to the home agent? The foreign agent forwards all "proper" requests that it receives and forwards them to the respective agents. Your (i+1) request is also forwarded to your HA. The replies of i and i+1 requests from the HA would be sent to the mobile node provided time out does not occur at the FA. >I am a little confused and maybe the answers would help me in my model. >Thanks, >Regards, >Meeta > Hope that helps. GSM Gowri S. Makineni Sr. Systems Engineer, Ecutel (703)354-4140 X-110 ---------------------------------------------------------- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 10 09:15: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 JAA03422 for ; Tue, 10 Oct 2000 09:15:18 -0400 (EDT) Received: from standards (47.234.32.16:1420) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0B28@standards.nortelnetworks.com>; Tue, 10 Oct 2000 9:00:28 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41912 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 10 Oct 2000 09:00:27 -0400 Received: from esebh01nok.ntc.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0B25@standards.nortelnetworks.com>; Tue, 10 Oct 2000 9:00:27 -0400 Received: by esebh01nok with Internet Mail Service (5.5.2652.78) id <4T9FSFMY>; Tue, 10 Oct 2000 16:04:00 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <6D1A8E7871B9D211B3B00008C7490AA504E622FA@treis03nok> Date: Tue, 10 Oct 2000 16:03:58 +0300 Reply-To: henry.haverinen@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Henry Haverinen Subject: [MOBILE-IP] draft-calhoun-diameter-mobileip-10.txt and existing authorization infrastructures To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi folks, For those that are interested in MIP/AAA issues, please have a look at the attached message, which I sent to this mailing list a week ago. Any comments most welcome! Regards, Henry > -----Original Message----- > From: EXT Henry Haverinen [mailto:henry.haverinen@NOKIA.COM] > Sent: 04. October 2000 15:31 > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] The use of existing authorization infrastructures > with Mobile IP/ AAA > > > Hi all, > > In summary, I propose the following additions to > draft-calhoun-diameter-mobileip-10.txt in this mail. > > 1. Two new rules for FA behavior when receiving the AMA > Command in response to the AMR Command: > > a) If the AMA Command doesn't contain a MIP-Reg-Reply AVP, > the FA must forward the Reg.Request in question > to the HA itself. > b) If the AMA Command includes the Result-Code AVP > set to an error, the FA sends the MN a Reg.Reply with an > error code but nevertheless includes any AAA or key > distribution extensions from the AMA Command. > > 2. One new rule for HA behaviour: > > If the HA receives a Registration Request that contains > the MN-AAA Authentication extension, either relayed by a > FA or directly from a MN that is registering a co-located > care-of address, the HA may issue the AMR Command in order > to authorize the Reg.Request. The AMR Command includes some > new flag which tells the AAA server that it does not have to > contact the home agent, and that the request came directly > from the home agent. > > --- > > The draft draft-haverinen-mobileip-gsmsim-00.txt describes how the > existing GSM authorization infrastructure can be leveraged to achieve > mobile user authorization for Mobile IP. The idea is not to use the > GSM radio access technology, but to show how GSM SIM authorization > could be used for Mobile IP authorization over any link layer, for > example on WLAN hot spots. I'm writing a new revision of the draft > which will fix the issues discussed on this mailing list and make the > protocol to use the Mobile IP AAA extensions, so that the mobility > agents don't need to be GSM SIM aware. > > The general model of leveraging an existing large scale > authorization/charging infrastructure is very important because > building new authorization infrastructures from scratch is hard: > getting the necessary contracts and agreements in place takes effort > and time. GSM authorization infrastructure is just one example of > an existing large scale authorization infrastructure. Another such > global infrastructure is the credit-card infra: e.g., consider > the following scenario: I travel to a new location, pay the local > ISP using my credit card, and continue to use Mobile IP with an HA > in my home ISP. > > In my opinion, any MIP/AAA proposal should be able to easily support > use of existing authorization infrastructures because it will greatly > speed up deployment of Mobile IP. However, the current MIP/AAA drafts > (e.g., draft-calhoun-diameter-mobileip-10.txt) have a couple of > assumptions that do not support such authorization. The important > aspect is that when existing authorization infrastructures are used, > HA and AAAH are not necessarily under the same administrative control, > and are not co-located. They are probably not even close to each > other. > > Let's use the term AAAH to denote the AAA server that can authorize > the user, and probably charge/bill the user where necessary. In the > GSM SIM case, the AAAH is the Authentication Centre (AuC) which > resides deep inside the GSM network. > > The foreign domain may have a local AAA network which includes a AAA > server that has an interface to the GSM network. In this case, the > local AAA network is able to reach the AAAH but the AAA network isn't > able to reach the home agent, as the current MIP/AAA drafts assume. > Suppose that a FA issues the DIAMETER AA-Mobile-Node-Request (AMR) > Command to authorize a Registration Request that uses GSM SIM. The > current view is that the the response from AAA (AA-Mobile-Node-Answer, > AMA Command) includes the Registration Reply from the HA in a > MIP-Reg-Reply AVP, which isn't possible in this case. > > One way to support such authorization would be to add a new rule to > the operation of the FA: if the response from the AAA doesn't contain > the Registration Reply, the FA must forward the request to the HA > itself. > > Besides the reachability of the HA through the AAA network, > the GSM SIM > authorization breaks another assumption. A mobile node that > is using GSM SIM is not able to provide the visited domain with > complete yet unforgeable credentials without ever having been in touch > with its home domain, as required in > draft-ietf-mobileip-aaa-reqs-04.txt. > This is because GSM SIM requires true challenge/response > authentication > where AAAH generates the challenge. In other words, it takes two round > trips to authorize the MN. The AAA response in the first round trip > contains the challenge. The result code in the response indicates that > the user was not authorized. > > True challenge/response could be supported by adding another > new rule to the operation of the FA: if the AAA responds to the > FA's authorization request with an error, the FA sends the MN a > Reg.Reply with an error code but nevertheless includes any AAA or key > distribution extensions from the AAA response. These > extensions contain > the challenge. The MN is now able to send another Reg.Request > for which > the authorization will be successful. > > The same approach can also be used to for authorization in the home > domain. Both HA and FA can use the same AAAH (located elsewhere) for > authorizing the mobile user. > > The HA may receive a Reg.Request (from a co-located MN or a FA) that > contains the MN-AAA Authentication extension. The HA could then pass > the request to the AAA network, for example with the DIAMETER AMR > Command, and the AAA network would respond with the AMA command, using > the AAAH on the GSM network. Here we probably need a new flag > in the AAA > request that tells the AAA server that it does not have to contact the > home agent, and that the request came directly from the home agent. > > > Regards, > Henry > > P.S. I'd like to acknowledge that Asokan (n.asokan@nokia.com) > has contributed a lot in these ideas and in this mail. Many thanks! > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 10 10:28: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 KAA04796 for ; Tue, 10 Oct 2000 10:28:39 -0400 (EDT) Received: from standards (47.234.32.16:2843) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0C0B@standards.nortelnetworks.com>; Tue, 10 Oct 2000 10:11:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 42218 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 10 Oct 2000 10:11:43 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:37101) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0C09@standards.nortelnetworks.com>; Tue, 10 Oct 2000 10:11:42 -0400 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 AAA28519; Wed, 11 Oct 2000 00:23:37 +1000 (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 BAA07835; Wed, 11 Oct 2000 01:25:55 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Wed, 11 Oct 2000 01:26:03 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C032C6.04693110" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB35D@eaubrnt018.epa.ericsson.se> Date: Wed, 11 Oct 2000 01:26:02 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] A practical question... X-To: "Thierry.Ernst@INRIALPES.FR" 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_01C032C6.04693110 Content-Type: text/plain Hi Thierry, Thanks for the quick reply Please see my comments below. Cheers, Hesham > > I believe your solution is perfect for one case : > > The devices connected to the MR do not have a MIPv6 implementation. > > Some people might argue that if you do not have a MIPv6 implementation > > then you should not be mobile. But that is also debatable I think. > > > If the devices have MIPv6 in them (ie. MN's) then they can manage > > their > > own mobility. There is a chapter on this in the HMIPv6 draft. In this > > case > > the MR advertises itself as a MAP upon entering a foreign network. > > As a result the MN's attached to it would register with the HA with an > > alt-CoA which is the MR's (MAP) address. > > > > It would be good to get your comments on this solution. > > As I understand your draft > http://ietf.org/internet-drafts/draft-ietf-mobileip-hmipv6-00.txt, the > MN enters the mobile network and listens to router advertisements. It > gets a LCOA and registers with the MAP, i.e the mobile router MR. It > adversites the MAP's address to its HA and its CNs. Fine. > No it doesn't need to get an on link CoA, it keeps the same address, ie Home address. The MR (MAP) get a new CoA (topologially correct). It registers with the HA. The MNs attached to the MR (MAP) register the MAP's address as an alt-CoA with the HA. All packets destined to the MNs get routed by the CNs to the MAP which then routes them to the MN's on link. > How packets get routed from the CN to the MN ? I understand that the > MAP's address is the home address of the MR. The MR also gets a > care-of address at each of its Access Router. Then, the packets sent > from CN to MN is sent to the MAP's address and the routing header > contains the home address of the MN. The packet gets routed to the HA > of the MR where it is encapulated to the current care-of address of the > MR as if the final destination was the MR itself. The final > destination is transparent to the HA. The packet is received and > decapsulated by MR and the desitnation address is switched with the one > contained in the routing header. The packet is then forwarded to the > MN. > > Your proposition therefore works for mobile nodes MNs visiting a mobile > network. (However, there is no optimal routing between CN and MN, but > this not the present subject of the discussion) > What do you mean by an optimal route between the CN and MN ? Route optimisation is used in this case. Is there a more optimal route ? > What about FIXED nodes located in the mobile network ? This was the > topic of my draft > http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobilei > p-v6-network. > For the same reasons as outlined in my draft, the packet sent from a CN > to a FIXED host located in the mobile network can not reach its final > destination. Packets are routed to the HA of the MR and then the HA > does not know what to do with them. Those enters in a loop until the > TTL expires. See the explanation in my draft. As a result, FIXED > nodes in the mobile network never see the packets sent from CNs. From > what I understand, your solution does address this issue. > I'll read your draft again, but I don't know what you mean by a FIXED host ? > I agree that your solution is fine for MNs that visit the mobile > network, but one shouldn't forget about those FIXED host located in the > mobile network. To me, the issue of routing packet from CNs to the > FIXED host is more important as this is more likely to happen. > > Cheers, > Thierry. > > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) > * http://www.inrialpes.fr/planete/people/ernst/Welcome.html ------_=_NextPart_001_01C032C6.04693110 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] A practical question...

Hi Thierry,

Thanks for the quick = reply
Please see my = comments below.

Cheers,
Hesham

    > I believe your solution is = perfect for one case :
    > The devices connected to the MR = do not have a MIPv6 implementation.
    > Some people might argue that if = you do not have a MIPv6 implementation
    > then you should not be mobile. = But that is also debatable I think.

    > If the devices have MIPv6 in them = (ie. MN's) then they can manage
    > their
    > own mobility. There is a chapter = on this in the HMIPv6 draft. In this
    > case
    > the MR advertises itself as a = MAP upon entering a foreign network.
    > As a result the MN's attached to = it would register with the HA with an
    > alt-CoA which is the MR's (MAP) = address.
    >
    > It would be good to get your = comments on this solution.

    As I understand your draft
    http://ietf.org/internet-drafts/draft-ietf-mobileip-hm= ipv6-00.txt, the
    MN enters the mobile network and = listens to router advertisements.   It
    gets a LCOA and registers with the = MAP, i.e the mobile router MR.   It
    adversites the MAP's address to its = HA and its CNs.   Fine.

    No it doesn't need = to get an on link CoA, it keeps the same address,
    ie Home address. = The MR (MAP) get a new CoA (topologially correct).
    It registers with = the HA. The MNs attached to the MR (MAP) register
    the MAP's address = as an alt-CoA with the HA. All packets destined
    to the MNs get = routed by the CNs to the MAP which then routes them
    to the MN's on = link.

    How packets get routed from the CN to = the MN ?  I understand that the
    MAP's address is the home address of = the MR.    The MR also gets a
    care-of address at each of its Access = Router.    Then, the packets sent
    from CN to MN is sent to the MAP's = address and the routing header
    contains the home address of the MN. = The packet gets routed to the HA
    of the MR where it is encapulated to = the current care-of address of the
    MR as if the final destination was = the MR itself.   The final
    destination is transparent to the = HA.   The packet is received and
    decapsulated by MR and the = desitnation address is switched with the one
    contained in the routing = header.  The packet is then forwarded to the
    MN.

    Your proposition therefore works for = mobile nodes MNs visiting a mobile
    network.  (However, there is no = optimal routing between CN and MN, but
    this not the present subject of the = discussion)

    What do you mean by = an optimal route between the CN and MN ?
    Route optimisation = is used in this case. Is there a more optimal route ?

    What about FIXED nodes located in the = mobile network ?  This was the
    topic of my draft
    http://www.inrialpes.fr/planete/people/ernst/Documents= /draft-ernst-mobileip-v6-network.
    For the same reasons as outlined in = my draft, the packet sent from a CN
    to a FIXED host located in the mobile = network can not reach its final
    destination.   Packets are = routed to the HA of the MR and then the HA
    does not know what to do with = them.  Those enters in a loop until the
    TTL expires.   See the = explanation in my draft.  As a result, FIXED
    nodes in the mobile network never see = the packets sent from CNs. From
    what I understand, your solution does = address this issue.

    I'll read your draft = again, but I don't know what you mean by a FIXED host ?


    I agree that your solution is fine for = MNs that visit the mobile
    network, but one shouldn't forget = about those FIXED host located in the
    mobile network.  To me, the = issue of routing packet from CNs to the
    FIXED host is more important as this = is more likely to happen.

    Cheers,
    Thierry.

    * mailto:Thierry.Ernst@inrialpe= s.fr  Tel +33 (0) 4 = 76 61 52 69
    * INRIA Rhone-Alpes Projet = PLANETE       (fax 52 52)
    * http://www.inrialpes.fr/planete/people/ernst/Welcome.h= tml

------_=_NextPart_001_01C032C6.04693110-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 10 11:01: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 LAA05551 for ; Tue, 10 Oct 2000 11:01:20 -0400 (EDT) Received: from standards (47.234.32.16:2843) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0C85@standards.nortelnetworks.com>; Tue, 10 Oct 2000 10:44:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 42381 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 10 Oct 2000 10:44:43 -0400 Received: from ebene.inrialpes.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0C83@standards.nortelnetworks.com>; Tue, 10 Oct 2000 10:44:43 -0400 Received: from galibier.inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id QAA16670; Tue, 10 Oct 2000 16:59:11 +0200 (MET DST) Received: from inrialpes.fr (localhost [127.0.0.1]) by galibier.inrialpes.fr (8.8.7/8.8.5) with ESMTP id QAA18347; Tue, 10 Oct 2000 16:59:11 +0200 (MET DST) X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <4B6BC00CD15FD2119E5F0008C7A419A5089EB35D@eaubrnt018.epa.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39E32EBF.61802283@inrialpes.fr> Date: Tue, 10 Oct 2000 16:59:11 +0200 Reply-To: Thierry.Ernst@INRIALPES.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Thierry Ernst Organization: INRIA Rhone-Alpes Subject: Re: [MOBILE-IP] A practical question... X-cc: "Hesham Soliman (EPA)" , thierry.ernst@crm.mot.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Hesham, Thank you for your precisions. > No it doesn't need to get an on link CoA, it keeps the same > address, > ie Home address. The MR (MAP) get a new CoA (topologially > correct). > It registers with the HA. The MNs attached to the MR (MAP) > register > the MAP's address as an alt-CoA with the HA. All packets destined > > to the MNs get routed by the CNs to the MAP which then routes > them > to the MN's on link. > What do you mean by an optimal route between the CN and MN ? > Route optimisation is used in this case. Is there a more optimal > route What care-of address contains the BU sent by the MN to its CNs ? It contains the MR 's address, right ? But the MR is also a mobile node, then the MR's address is in fact a home address. Packets from the CN to the MN therefore get routed to the MR's HA. There is no true route optimisation. It is true that packets do not transit by the MN's HA, otherwise you would end up in a double redirection. > > I'll read your draft again, but I don't know what you mean by a > FIXED host ? A mobile network is not only a router, but a mobile router and all its attached nodes. Those attached nodes are FIXED relative to the MR. The Mobile Network might even be composed of several routers (i.e. a set of subnetworks). A Mobile Node is a node that is visiting the mobile network by opposition to the FIXED nodes that always remain located in the mobile network (let's call them Mobile Network Nodes - nodes from the mobile network - MNNs). Cheers, Thierry. * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) * http://www.inrialpes.fr/planete/people/ernst/Welcome.html From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 10 11:12: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 LAA05794 for ; Tue, 10 Oct 2000 11:12:07 -0400 (EDT) Received: from standards (47.234.32.16:2843) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0CD9@standards.nortelnetworks.com>; Tue, 10 Oct 2000 10:55:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 42487 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 10 Oct 2000 10:55:16 -0400 Received: from qhars002.nortel.com (47.101.112.102:65095) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0CD7@standards.nortelnetworks.com>; Tue, 10 Oct 2000 10:55:15 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Tue, 10 Oct 2000 16:08:37 +0100 Received: from zrchs148 by smtprch1.nortel.com; Tue, 10 Oct 2000 10:04:07 -0500 Received: from zrchb200.us.nortel.com (actually zrchb200) by zrchs148; Tue, 10 Oct 2000 09:55:32 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 10 Oct 2000 10:03:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C032CB.32669F30" Message-ID: <36FA02BD7083D411BC9E0000F8073E438CEECC@crchy271.us.nortel.com> Date: Tue, 10 Oct 2000 10:03:07 -0500 Reply-To: Glenn Morrow Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Glenn Morrow Subject: Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup port in IPv6"draft] X-To: Fred Baker To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM ------_=_NextPart_001_01C032CB.32669F30 Content-type: text/plain; charset="iso-8859-1" fb> > how do you detect the bozos? I think the argument for using ingress > filtering all the time is that it does indeed detect most bozos. > gm> Yes, I believe the bozos (aagh - what have I started?) should be detected on the first hop all of the time. I think we agree. fb> By the way, the most usual implementation of ingress filtering goes rather > beyond what the RFC actually says - it uses a reverse path forwarding > check. This has its own dangers, however, related to asymmetric routing. > Ingress filtering says "if you are among a few known bad things, I will > detect you", meaning that on every packet I have to apply a number of > rules. RPF says "if it would be reasonable for me to forward to you along > this path, I will let you forward via me", which happens to be a single > lookup way to apply a much stronger rule set. But asymmetric routing may > make it possible only for you to forward via me while I consider quite > another route to be my most reasonable route to you. Hence, ingress > filtering is usually only done at the edge-network-to-ISP interface; > ISP-ISP interfaces get eaten by asymmetric routing pretty badly. > gm> Good points, thanks for bringing these up. fb> > I personally would favor a form of ingress filtering that ensures that > only > addresses that may be found on a first-hop-router interface get used as > sources - in short, that the MAC Source Address and the IP Source Address > indeed match at the first hop, or on a dial line, that the Source IP > Address is the one that was assigned to the device dialing in. This would > detect a lot of bozo addressing. > gm> me too for the IP source address. I'm not so sure about the MAC address for all cases. fb> > From an operational perspective, though, > unless we made this somehow mandatory to turn on and had laws that imposed > stiff fines for turning it off, operators could never trust it; they would > need to do their own RPF checks anyway, as this is the only defense that > they could control. > gm> Making it a standard BCP for IPv6 might be all that is needed. A method of propagating amoung autonomous systems the turning of ingress filtering on and off on specific routes might allow for the detection of the attackers' network or address. Once detected, the offending nodes' connectivity could be prevented and then the filtering removed. The drafts I mentioned are possibly the beginnings of such functionality. Think of it like a tool for detecting the location of the attacking node(s) and acting upon them. If such a tool were available, it would allow detection and prosecution using existing laws. If no remedies for prosecution were available and the provider refuses to enable the 1st hop filtering, the offending network might have to be denied at the AS level as purely a business decision of other providers. I could see how this might happen among belligerents across national borders. fb> > And yes, I think they do in fact turn on the RPF check when they think it > is appropriate, in many cases, as opposed to leaving it on all the time. > > Note that if I require the IP Source Address and the MAC Address to match, > I just made COA addresses a failure case... This would have to be seen as > an acceptable exception. > gm> I'm not so sure about the MAC address needing to match for all cases. The standard first hop ingress filtering would work for the COA address without any additional routes etc.. in the first hop router. The use of the home address as the source address would likely require that the first hop access router implement the concept of a binding cache. If the route is in the binding cache then ingress filtering probably does not need to be done. This assumes that very strong AAA is done before any entry is made into this binding cache - no matter what method of network access and COA assignment is used. I would enjoy continuing this conversation, you seem to have a very good insight into the problem space and current deployed solution set. I'm more interested in getting node mobility built into IPv6 the right way for the long term at this point. I do not want to focus on IPv4 deployment issues that may arise with existing implementations. It seems that getting strong BCPs in place for ingress filtering in IPv6 with node mobility in mind is an important step in this regard. It seems that most people are supportive of limiting the filtering to the edges of the network. This would help mobility immensely in that home addresses could be used as the source address and remove a bunch of issues with tunneling. How do think we could proceed, if at all, on these matters? Thanks, Glenn ------_=_NextPart_001_01C032CB.32669F30 Content-type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of = "MobilitySup port in IPv6"draft]

    fb>
    how do you detect the bozos? I think = the argument for using ingress
    filtering all the time is that it = does indeed detect most bozos.

    gm> Yes, I = believe the bozos (aagh - what have I started?) should be detected on = the first hop all of the time. I think we agree.


    fb>
    By the way, the most usual implementation of = ingress filtering goes rather
    beyond what the RFC actually says - = it uses a reverse path forwarding
    check. This has its own dangers, = however, related to asymmetric routing.
    Ingress filtering says "if you = are among a few known bad things, I will
    detect you", meaning that on = every packet I have to apply a number of
    rules. RPF says "if it would be = reasonable for me to forward to you along
    this path, I will let you forward via = me", which happens to be a single
    lookup way to apply a much stronger = rule set. But asymmetric routing may
    make it possible only for you to = forward via me while I consider quite
    another route to be my most = reasonable route to you. Hence, ingress
    filtering is usually only done at the = edge-network-to-ISP interface;
    ISP-ISP interfaces get eaten by = asymmetric routing pretty badly.

    gm> Good points, = thanks for bringing these up.=20

    fb>
    I personally would favor a form of = ingress filtering that ensures that only
    addresses that may be found on a = first-hop-router interface get used as
    sources - in short, that the MAC = Source Address and the IP Source Address
    indeed match at the first hop, or on = a dial line, that the Source IP
    Address is the one that was assigned = to the device dialing in. This would
    detect a lot of bozo = addressing.=20

    gm> me too for = the IP source address. I'm not so sure about the MAC address for all = cases.

    fb>
    From an operational perspective, = though,
    unless we made this somehow mandatory = to turn on and had laws that imposed
    stiff fines for turning it off, = operators could never trust it; they would
    need to do their own RPF checks = anyway, as this is the only defense that
    they could control.

    gm> Making it a = standard BCP for IPv6 might be all that is needed.

    A method of = propagating amoung autonomous systems the turning of ingress filtering = on and off on specific routes might allow for the detection of the = attackers' network or address. Once detected, the offending nodes' = connectivity could be prevented and then the filtering = removed.

    The drafts I = mentioned are possibly the beginnings of such functionality.  = Think of it like a tool for detecting the location of the attacking = node(s) and acting upon them.

    If such a tool were = available, it would allow detection and prosecution using existing = laws.

    If no remedies for = prosecution were available and the provider refuses to enable the 1st = hop filtering, the offending network might have to be denied at the AS = level as purely a business decision of other providers. I could see how = this might happen among belligerents across national = borders.

    fb>
    And yes, I think they do in fact turn = on the RPF check when they think it
    is appropriate, in many cases, as = opposed to leaving it on all the time.

    Note that if I require the IP Source = Address and the MAC Address to match,
    I just made COA addresses a failure = case... This would have to be seen as
    an acceptable exception.

    gm> I'm not so = sure about the MAC address needing to match for all cases. The standard = first hop ingress filtering would work for the COA address without any = additional routes etc.. in the first hop router.

    The use of the home = address as the source address would likely require that the first hop = access router implement the concept of a binding cache. If the route is = in the binding cache then ingress filtering probably does not need to = be done. This assumes that very strong AAA is done before any entry is = made into this binding cache - no matter what method of network access = and COA assignment is used.

    I would enjoy = continuing this conversation, you seem to have a very good insight into = the problem space and current deployed solution set. I'm more = interested in getting node mobility built into IPv6 the right way for = the long term at this point.

    I do not want to = focus on IPv4 deployment issues that may arise with existing = implementations.

    It seems that = getting strong BCPs in place for ingress filtering in IPv6 with node = mobility in mind is an important step in this regard.

    It seems that most = people are supportive of limiting the filtering to the edges of the = network. This would help mobility immensely in that home addresses = could be used as the source address and remove a bunch of issues with = tunneling.

    How do think we = could proceed, if at all, on these matters?

    Thanks,

    Glenn

------_=_NextPart_001_01C032CB.32669F30-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 10 13:05: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 NAA08425 for ; Tue, 10 Oct 2000 13:05:28 -0400 (EDT) Received: from standards (47.234.32.16:2843) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0DE1@standards.nortelnetworks.com>; Tue, 10 Oct 2000 12:48:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 42805 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 10 Oct 2000 12:48:44 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0DBA@standards.nortelnetworks.com>; Tue, 10 Oct 2000 12:38:44 -0400 Received: from 209.162.52.62 (209-162-52-62.thegrid.net [209.162.52.62]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id LAA24200 for ; Tue, 10 Oct 2000 11:53:29 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <00000b6b483f$00005d32$000031a5@209.162.52.62> Date: Tue, 10 Oct 2000 07:52:00 -0700 Reply-To: leah262@EXCITE.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: leah262@EXCITE.COM Subject: [MOBILE-IP] $131 per month total health insurance X-To: mobile-ip@smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: quoted-printable Best Buy
For Medical Insurance
Highest Rating ( includes)

* Choice of Doctors-$10 co / pay, unlimited visits.
* 100% Coverage-$10 co / pay.
* Health Club Membership.
* Dental Insurance.
* Vision care.
* Chiropractic care, $20 co / pay, 20 visits / year.
* Hospital stay, intensive care, cardiac care, general nursing
care, meals and special diets, $100 deductible at admission.
* And lots more.
* also specializing in groups.
No matter what age or where you live
Health and Dental Insurance.
$ 131 for single
$ 245 for couple
$362 per family

to see if you qualify
Call toll free (866) 689-6463 ask for Mike lic.0537829=




To be removed go to: health111@excite.com
Type REMOVE in subject line.Thank you

From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 10 13: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 NAA09020 for ; Tue, 10 Oct 2000 13:41:05 -0400 (EDT) Received: from standards (47.234.32.16:2843) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0E6B@standards.nortelnetworks.com>; Tue, 10 Oct 2000 13:24:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 43020 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 10 Oct 2000 13:24:28 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0E5F@standards.nortelnetworks.com>; Tue, 10 Oct 2000 13:14:27 -0400 Received: from china.com (209-63-113-41.sea.jps.net [209.63.113.41]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id MAA24401 for ; Tue, 10 Oct 2000 12:29:04 -0500 (CDT) X-Sender: cars@consumersvccenter.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <200010101729.MAA24401@hosaka.smallworks.com> Date: Tue, 10 Oct 2000 13:21:26 -0600 Reply-To: cars@CONSUMERSVCCENTER.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: cars@CONSUMERSVCCENTER.COM Subject: [MOBILE-IP] Best Prices On New Cars!!!!!! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM ________________________________________________________________________ The Consumer Service Center has recently acquired a list of opt-in subscribers interested in offers for consumer services and products. We will continue to bring you valuable offers on the products and services that interest you most. If you feel you are somehow on this list in error, please use the remove link at the bottom of the page. ________________________________________________________________________ Get A Great Price On A New Car! Absolutely Free! Want to save time and money? Want to have quick access to car quotes? Want to have all makes and models available to you? If you answered yes to any of these, then take advanage of this free, no-hassle service. Simply click on the link below to get low prices on all makes and models of new cars, without having to negotiate with a dealer. It's painless and stress-free! GO TO http://www.consumersvccenter.com/cgi-bin/carform.cgi NOW FOR BEST DEALS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This mail is never sent unsolicited. To unsubscribe use the link below mailto:remove@consumersvccenter.com?subject=Remove If you have a product or service you think might qualify you can find contact info at http://www.consumersvccenter.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 10 17:17: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 RAA13591 for ; Tue, 10 Oct 2000 17:17:46 -0400 (EDT) Received: from standards (47.234.32.16:1231) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0FB1@standards.nortelnetworks.com>; Tue, 10 Oct 2000 17:01:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 43446 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 10 Oct 2000 17:01:02 -0400 Received: from quartz.airtouch.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0FA1@standards.nortelnetworks.com>; Tue, 10 Oct 2000 16:51:01 -0400 Received: from Notes.airtouch.com (ath-irv-smtp1.it.cl.airtouch.com [153.114.55.212]) by quartz.airtouch.com (8.8.8+Sun/8.8.8) with SMTP id OAA26597; Tue, 10 Oct 2000 14:14:14 -0700 (PDT) Received: by Notes.airtouch.com(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id 88256974.0073BDB3 ; Tue, 10 Oct 2000 14:04:12 -0700 X-Lotus-FromDomain: AIRTOUCH Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=n9nrpCyzuNeIgdxmGIoHo9Oxh2PTxEQ0bquHgQZkYLFR72ZUlwCql5HG" Content-Disposition: inline Message-ID: <88256974.0073BCC4.00@Notes.airtouch.com> Date: Tue, 10 Oct 2000 14:03:43 -0700 Reply-To: Bryan.Cook@NOTES.AIRTOUCH.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Bryan Cook Subject: Re: [MOBILE-IP] $131 per month total health insurance X-To: leah262@EXCITE.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --0__=n9nrpCyzuNeIgdxmGIoHo9Oxh2PTxEQ0bquHgQZkYLFR72ZUlwCql5HG Content-type: text/plain; charset=us-ascii Content-Disposition: inline How much commercial garbage can we expect to get on this list server? leah262@EXCITE.COM on 10/10/2000 07:52:00 AM Please respond to leah262@EXCITE.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Bryan Cook/Corporate/AirTouch) Subject: [MOBILE-IP] $131 per month total health insurance --0__=n9nrpCyzuNeIgdxmGIoHo9Oxh2PTxEQ0bquHgQZkYLFR72ZUlwCql5HG Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PEhUTUw+DQo8Qk9EWT4NCg0KPEZPTlQgZmFjZT0iTVMgU2FucyBTZXJpZiI+DQo8Rk9OVCBzaXpl PTQ+DQo8Rk9OVCBjb2xvcj0iIzAwMDAwMCI+ICAgICAgICAgICAgICAgICAgICAgIDwvRk9OVD4N CjxGT05UIGNvbG9yPSIjMDAwMEZGIj4gICA8L0ZPTlQ+DQo8Rk9OVCBzaXplPTU+DQo8Rk9OVCBj b2xvcj0iIzAwMDBGRiI+ICAgPC9GT05UPg0KPEZPTlQgZmFjZT0iSW1wYWN0Ij4NCjxGT05UIGNv bG9yPSIjMDAwMEZGIj4gICAgICA8L0ZPTlQ+DQo8Rk9OVCBjb2xvcj0iIzAwMDBGRiI+PEI+IEJl c3QgIEJ1eTwvQj48L0ZPTlQ+DQo8Rk9OVCBmYWNlPSJNUyBTYW5zIFNlcmlmIj4NCjxGT05UIHNp emU9ND4NCjxGT05UIGNvbG9yPSIjMDAwMEZGIj4gPEJSPg0KICAgICAgICAgICAgICAgIDwvRk9O VD4NCjxGT05UIHNpemU9ND4NCjxGT05UIGNvbG9yPSIjMDAwMEZGIj4gICAgRm9yIE1lZGljYWwg SW5zdXJhbmNlPC9GT05UPg0KPEZPTlQgc2l6ZT00Pg0KPEZPTlQgY29sb3I9IiMwMDAwRkYiPiA8 QlI+DQogICAgICAgICAgICAgICAgICAgICBIaWdoZXN0IFJhdGluZyAgKCBpbmNsdWRlcyk8QlI+ DQo8QlI+DQoqIENob2ljZSBvZiBEb2N0b3JzLSQxMCBjbyAvIHBheSwgdW5saW1pdGVkIHZpc2l0 cy48QlI+DQoqIDEwMCUgQ292ZXJhZ2UtJDEwIGNvIC8gcGF5LjxCUj4NCiogSGVhbHRoIENsdWIg TWVtYmVyc2hpcC48QlI+DQoqIERlbnRhbCBJbnN1cmFuY2UuPEJSPg0KKiBWaXNpb24gY2FyZS48 QlI+DQoqIENoaXJvcHJhY3RpYyBjYXJlLCAkMjAgY28gLyBwYXksIDIwIHZpc2l0cyAvIHllYXIu PEJSPg0KKiBIb3NwaXRhbCBzdGF5LCBpbnRlbnNpdmUgY2FyZSwgY2FyZGlhYyBjYXJlLCBnZW5l cmFsIG51cnNpbmc8QlI+DQogIGNhcmUsIG1lYWxzIGFuZCBzcGVjaWFsIGRpZXRzLCAkMTAwIGRl ZHVjdGlibGUgYXQgYWRtaXNzaW9uLjxCUj4NCiogQW5kIGxvdHMgbW9yZS48QlI+DQoqIGFsc28g c3BlY2lhbGl6aW5nIGluIGdyb3Vwcy48QlI+DQo8L0ZPTlQ+DQo8Rk9OVCBzaXplPTQ+DQo8Rk9O VCBjb2xvcj0iIzAwMDBGRiI+IDxCUj4NCk5vIG1hdHRlciB3aGF0IGFnZSBvciB3aGVyZSB5b3Ug bGl2ZTxCUj4NCkhlYWx0aCBhbmQgRGVudGFsIEluc3VyYW5jZS48L0ZPTlQ+DQo8Rk9OVCBzaXpl PTQ+DQo8Rk9OVCBjb2xvcj0iIzAwMDBGRiI+IDxCUj4NCiAgICAgICAgICAgICAgICAgICAgIDwv Rk9OVD4NCjxGT05UIHNpemU9ND4NCjxGT05UIGNvbG9yPSIjMDAwMEZGIj4gICQgMTMxIGZvciBz aW5nbGU8QlI+DQogICAgICAgICAgICAgICAgICAkIDI0NSBmb3IgY291cGxlICA8QlI+DQogICAg ICAgICAgICAgICAgICAkMzYyIHBlciBmYW1pbHk8L0ZPTlQ+DQo8Rk9OVCBzaXplPTQ+DQo8Rk9O VCBjb2xvcj0iIzAwMDBGRiI+IDxCUj4NCiAgICAgICAgICAgICAgICAgPEJSPg0KICAgICAgICAg ICAgICAgICAgICAgdG8gc2VlIGlmIHlvdSBxdWFsaWZ5PEJSPg0KICAgICAgICAgICAgICAgICAg IENhbGwgdG9sbCBmcmVlICAoODY2KSA2ODktNjQ2MyBhc2sgZm9yIE1pa2UgbGljLjA1Mzc4Mjk8 QlI+DQo8QlI+DQo8QlI+DQo8QlI+DQo8QlI+DQpUbyBiZSByZW1vdmVkIGdvIHRvOiAgaGVhbHRo MTExQGV4Y2l0ZS5jb208QlI+DQpUeXBlIFJFTU9WRSBpbiBzdWJqZWN0IGxpbmUuVGhhbmsgeW91 PC9GT05UPg0KPEZPTlQgY29sb3I9IiMwMDAwMDAiPiA8QlI+DQo8L0ZPTlQ+PC9GT05UPjwvRk9O VD48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9GT05U PjwvRk9OVD48cD48cD48cD48cD48cD48cD48cD48cD48cD48cD4NCg0KDQoNCg0KDQoNCg0KPHA+ PEZPTlQgZmFjZT0iTVMgU2FucyBTZXJpZiI+PHA+PC9CT0RZPjwvSFRNTD4NCg== --0__=n9nrpCyzuNeIgdxmGIoHo9Oxh2PTxEQ0bquHgQZkYLFR72ZUlwCql5HG-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 10 17:46: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 RAA14021 for ; Tue, 10 Oct 2000 17:46:10 -0400 (EDT) Received: from standards (47.234.32.16:1231) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA102B@standards.nortelnetworks.com>; Tue, 10 Oct 2000 17:29:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 43627 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 10 Oct 2000 17:29:33 -0400 Received: from smtp-2.hut.fi by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1027@standards.nortelnetworks.com>; Tue, 10 Oct 2000 17:19:32 -0400 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 AAA52925; Wed, 11 Oct 2000 00:34:13 +0300 (EEST) X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 References: <200010042150.OAA21514@nasnfs.eng.sun.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <39E38BD0.937CC926@cc.hut.fi> Date: Wed, 11 Oct 2000 00:36:16 +0300 Reply-To: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" Organization: HUT Subject: Re: [MOBILE-IP] MIP implementation !!! X-To: Vipul Gupta To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hello. Vipul Gupta wrote: > > Other Linux implementations are available from: > > o National University of Singapore (http://mip.ee.nus.sg/) > > o Stanford University as part of the Mosquitonet project > (http://mosquitonet.stanford.edu/) > I would add Dynamics -- HUT Mobile IP from Helsinki University of Technology, Finland. Dynamics works on Linux 2.2 (And has been compiled on a Linux in iPAQ even ;). There is pretty much doucmentation available from two master's theses to couple of conference papers and the current results of Dynamics code documentation project. The URL is below in the signature. Regards, Tom -- Tom Weckström Dynamics group Helsinki University of Technology dynamics@cs.hut.fi http://www.cs.hut.fi/Research/Dynamics/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 10 18:03: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 SAA14314 for ; Tue, 10 Oct 2000 18:03:00 -0400 (EDT) Received: from standards (47.234.32.16:1231) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1089@standards.nortelnetworks.com>; Tue, 10 Oct 2000 17:46:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 43738 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 10 Oct 2000 17:46:21 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1079@standards.nortelnetworks.com>; Tue, 10 Oct 2000 17:36:21 -0400 Received: from purol.East.Sun.COM ([129.148.9.11]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA12381; Tue, 10 Oct 2000 14:51:03 -0700 (PDT) Received: from onion.east.sun.com (onion [129.148.174.110]) by purol.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id RAA24323; Tue, 10 Oct 2000 17:51:02 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Tue, 10 Oct 2000 17:50:54 -0400 Reply-To: Steven Glass - Solaris Software Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Steven Glass - Solaris Software Subject: Re: [MOBILE-IP] $131 per month total health insurance X-To: Bryan.Cook@NOTES.AIRTOUCH.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <88256974.0073BCC4.00@Notes.airtouch.com> > > How much commercial garbage can we expect to get on this list server? I reached my breaking point a while ago, but what can you do? Well, glad I asked! You can require the poster to be subscribed. Yes, it'll be possible for someone to {subscribe, spam, unsubscribe}, but since we *also* require email confirmation (e.g. subscribe causes a "someone (probably you) has requested this email address be added to " email to be generated to , please reply with ########## to be added to ) means: - the posting address must be reachable - no more spamming from unreply-able email addresses, which will likely make spammers feel more accountable, so they [likely] go away, and - no more spaming from the auto-spammers which (IMHO) will remove [somethine like / at least / whatever] 85% of the spam we see. Yes, it also means if you're subscribed as you can't post from unless your mailer allows you to change from and/or reply-to, and your ISP allows you to post (apparently) from a non-ISP account. Again, IMHO, I don't think that's a high price to pay to return to mostly content on this list. Any chance we could [agree to] at least *try* this!?! Cheers, Steve > leah262@EXCITE.COM on 10/10/2000 07:52:00 AM > > Please respond to leah262@EXCITE.COM > > > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Bryan Cook/Corporate/AirTouch) > Subject: [MOBILE-IP] $131 per month total health insurance > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 10 20:47: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 UAA16222 for ; Tue, 10 Oct 2000 20:47:12 -0400 (EDT) Received: from standards (47.234.32.16:1111) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1172@standards.nortelnetworks.com>; Tue, 10 Oct 2000 20:30:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 44064 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 10 Oct 2000 20:30:27 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:47151) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1170@standards.nortelnetworks.com>; Tue, 10 Oct 2000 20:30:25 -0400 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 KAA25312; Wed, 11 Oct 2000 10:41:18 +1000 (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 LAA11604; Wed, 11 Oct 2000 11:43:35 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Wed, 11 Oct 2000 11:43:43 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0331C.4D2F4BE0" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB362@eaubrnt018.epa.ericsson.se> Date: Wed, 11 Oct 2000 11:43:41 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] A practical question... X-cc: thierry.ernst@crm.mot.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_001_01C0331C.4D2F4BE0 Content-Type: text/plain Hi Thierry, Some more comments below. Cheers, Hesham > > No it doesn't need to get an on link CoA, it keeps the same > > address, > > ie Home address. The MR (MAP) get a new CoA (topologially > > correct). > > It registers with the HA. The MNs attached to the MR (MAP) > > register > > the MAP's address as an alt-CoA with the HA. All packets destined > > > > to the MNs get routed by the CNs to the MAP which then routes > > them > > to the MN's on link. > > > What do you mean by an optimal route between the CN and MN ? > > Route optimisation is used in this case. Is there a more optimal > > route > > What care-of address contains the BU sent by the MN to its CNs ? It > contains the MR 's address, right ? But the MR is also a mobile node, > then the MR's address is in fact a home address. Packets from the CN > to the MN therefore get routed to the MR's HA. There is no true route > optimisation. It is true that packets do not transit by the MN's HA, > otherwise you would end up in a double redirection. > Ah, now I see what you mean. Sorry if this was not clear in the mail and the draft, I know the draft doesn't explain it very well but we're having a second revision before San Diego and hopefully this section will be better explained. So let me answer your concern. What I meant to say was that the MR (MAP) will advertise its CoA for the MN's (or what you call FIXED) to use as alternate-CoA. So in that way you're always getting route optimised packets, ie. not via the HA. Does that make sense ? Of course this means that every time the MR will do a handoff, a new option will be advertised with a new address. > > > > I'll read your draft again, but I don't know what you mean by a > > FIXED host ? > > > A mobile network is not only a router, but a mobile router and all its > attached nodes. Those attached nodes are FIXED relative to the MR. > The Mobile Network might even be composed of several routers (i.e. a set > of subnetworks). > > A Mobile Node is a node that is visiting the mobile network by > opposition to the FIXED nodes that always remain located in the mobile > network (let's call them Mobile Network Nodes - nodes from the mobile > network - MNNs). > Ok, I understand now, thanks. ------_=_NextPart_001_01C0331C.4D2F4BE0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] A practical question...

Hi Thierry,

Some more comments = below.

Cheers,
Hesham

    >      No = it doesn't need to get an on link CoA, it keeps the same
    >      = address,
    >      ie = Home address. The MR (MAP) get a new CoA (topologially
    >      = correct).
    >      It = registers with the HA. The MNs attached to the MR (MAP)
    >      = register
    >      = the MAP's address as an alt-CoA with the HA. All packets = destined
    >
    >      to = the MNs get routed by the CNs to the MAP which then routes
    >      = them
    >      to = the MN's on link.

    >      = What do you mean by an optimal route between the CN and MN ?
    >      = Route optimisation is used in this case. Is there a more optimal
    >      = route

    What care-of address contains the BU = sent by the MN to its CNs ?   It
    contains the MR 's address, right = ?  But the MR is also a mobile node,
    then the MR's address is in fact a = home address.   Packets from the CN
    to the MN therefore get routed to the = MR's HA.   There is no true route
    optimisation.   It is true = that packets do not transit by the MN's HA,
    otherwise you would end up  in a = double redirection.

    Ah, now I see what = you mean. Sorry if this was not clear in the
    mail and the draft, = I know the draft doesn't explain it very well but
    we're having a = second revision before San Diego and hopefully this
    section will be = better explained. So let me answer your concern.
    What I meant to say = was that the MR (MAP) will advertise its
    CoA for the MN's = (or what you call FIXED) to use as alternate-CoA.
    So in that way = you're always getting route optimised packets,
    ie. not via the HA. =
    Does that make = sense ? Of course this means that every time
    the MR will do a = handoff, a new option will be advertised with a
    new address. =

    >
    >      = I'll read your draft again, but I don't know what you mean by a
    >      = FIXED host ?


    A mobile network is not only a router, = but a mobile router and all its
    attached nodes.  Those attached = nodes are FIXED relative to the MR. 
    The Mobile Network might even be = composed of several routers (i.e. a set
    of = subnetworks).    

    A Mobile Node is a node that is = visiting the mobile network by
    opposition to the FIXED nodes that = always remain located in the mobile
    network (let's call them Mobile = Network Nodes - nodes from the mobile
    network - MNNs).

    Ok, I understand = now, thanks.

------_=_NextPart_001_01C0331C.4D2F4BE0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 02:30: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 CAA03794 for ; Wed, 11 Oct 2000 02:30:44 -0400 (EDT) Received: from standards (47.234.32.16:1219) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA132F@standards.nortelnetworks.com>; Wed, 11 Oct 2000 2:13:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 44651 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 02:13:54 -0400 Received: from stargate.ipunplugged.com (195.42.212.161:23027) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA132D@standards.nortelnetworks.com>; Wed, 11 Oct 2000 2:13:54 -0400 Received: from FREDRIKJPC ([192.168.4.218]) by stargate.ipunplugged.com (8.9.3/8.9.3) with SMTP id IAA26392 for ; Wed, 11 Oct 2000 08:26:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Message-ID: Date: Wed, 11 Oct 2000 08:30:18 +0300 Reply-To: Fredrik Johansson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fredrik Johansson Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <041901c02fa1$a5f65bc0$88b2d5a5@keg.telecom.samsung.co.kr> Content-Transfer-Encoding: 7bit Hi, the mobile node generates the challenge and send the request to the home agent. The home agent will then include the same challenge in the registration reply, is it up to the implementation of the co-located foreign agent to remove the challenge before giving it to the mobile client so it is not misstaken for a new challenge that can be sent in the registration reply for use in the next registration? /Fredrik > -----Original Message----- > From: IP Routing for Wireless/Mobile Hosts (mobile-ip) > [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Woo-June Kim > Sent: den 6 oktober 2000 17:28 > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA > > > Fredrik, > > The mobile node itself just generates a random number to use as > the challenge. The response can only be correctly calculated by > the mobile if it knows the correct key and algorithm. The AAA is > simply using this fact to check the mobile's identity in a > round-about manner. The challenge value itself is not something > that must be generated in some special manner. > > cheers > > >BlankHi > > > >I have a question concerning how Challenge / Response is supposed to work > >when a mobile node registers using a co-located foreign agent. > > > >Since the mobile node does not receive an advertisement with a challenge > >from a FA it cannot calculate a response to be used in a MN-AAA > >Authentication extension, i.e., the Home Agent cannot use a > Radius server to > >authenticate the MN. > > > >Have there been any thoughts in this area, or perhaps a solution in an > >earlier thread that I've missed? Thankful for any pointers. > > > >Regards > >/Fredrik > >----------------------------------------- > >Fredrik Johansson > > > >W: +46 (0)8 725 5916 > >M: +46 (0)70 786 5035 > >mailto:Fredrik.Johansson@ipunplugged.com > >http://www.ipunplugged.com > > > > > > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 02:48: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 CAA03885 for ; Wed, 11 Oct 2000 02:47:58 -0400 (EDT) Received: from standards (47.234.32.16:1219) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1380@standards.nortelnetworks.com>; Wed, 11 Oct 2000 2:31:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 44756 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 02:31:16 -0400 Received: from ms.samsung.com (211.45.29.136:49199) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA137E@standards.nortelnetworks.com>; Wed, 11 Oct 2000 2:31:15 -0400 Received: from keg ([203.244.218.1]) by ms.samsung.com (Netscape Messaging Server 4.15) with SMTP id G296RC00.7QK for ; Wed, 11 Oct 2000 15:45:12 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Message-ID: <001c01c0334d$27342100$88b2d5a5@keg.telecom.samsung.co.kr> Date: Wed, 11 Oct 2000 15:33:22 +0900 Reply-To: Woo-June Kim Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Woo-June Kim Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id CAA03885 Yes. >Hi, > >the mobile node generates the challenge and send the request to the home >agent. The home agent will then include the same challenge in the >registration reply, is it up to the implementation of the co-located foreign >agent to remove the challenge before giving it to the mobile client so it is >not misstaken for a new challenge that can be sent in the registration reply >for use in the next registration? > >/Fredrik > >> -----Original Message----- >> From: IP Routing for Wireless/Mobile Hosts (mobile-ip) >> [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Woo-June Kim >> Sent: den 6 oktober 2000 17:28 >> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >> Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA >> >> >> Fredrik, >> >> The mobile node itself just generates a random number to use as >> the challenge. The response can only be correctly calculated by >> the mobile if it knows the correct key and algorithm. The AAA is >> simply using this fact to check the mobile's identity in a >> round-about manner. The challenge value itself is not something >> that must be generated in some special manner. >> >> cheers >> >> >BlankHi >> > >> >I have a question concerning how Challenge / Response is supposed to work >> >when a mobile node registers using a co-located foreign agent. >> > >> >Since the mobile node does not receive an advertisement with a challenge >> >from a FA it cannot calculate a response to be used in a MN-AAA >> >Authentication extension, i.e., the Home Agent cannot use a >> Radius server to >> >authenticate the MN. >> > >> >Have there been any thoughts in this area, or perhaps a solution in an >> >earlier thread that I've missed? Thankful for any pointers. >> > >> >Regards >> >/Fredrik >> >----------------------------------------- >> >Fredrik Johansson >> > >> >W: +46 (0)8 725 5916 >> >M: +46 (0)70 786 5035 >> >mailto:Fredrik.Johansson@ipunplugged.com >> >http://www.ipunplugged.com > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 02:55: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 CAA03962 for ; Wed, 11 Oct 2000 02:55:10 -0400 (EDT) Received: from standards (47.234.32.16:1219) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA13C9@standards.nortelnetworks.com>; Wed, 11 Oct 2000 2:37:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 44850 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 02:37:55 -0400 Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA13C7@standards.nortelnetworks.com>; Wed, 11 Oct 2000 2:37:55 -0400 Received: from gopal.cisco.com (gdommety-dsl3.cisco.com [10.19.17.140]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id XAA21401; Tue, 10 Oct 2000 23:52:37 -0700 (PDT) X-Sender: gdommety@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.3.2.7.2.20001010233421.00ce6cc0@omega.cisco.com> Date: Tue, 10 Oct 2000 23:55:09 -0700 Reply-To: Gopal Dommety Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gopal Dommety Subject: Re: [MOBILE-IP] WG Last Call - (draft-ietf-mobileip-reg-tunnel-03.txt) X-To: Basavaraj.Patil@NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E359@daeis07nok> Hello Eva, Annika, and Charlie: Couple of questions/concerns regarding the reg-tunnel-03.txt 1. What is the fundamental reason for introducing new regional registration request/reply messages. I think this is unnecessary introduction of new message types. a) You are using extensions for the initial registration through the GFA. You could as well use the extensions for achieving regional registrations. b) In fact your version 02 of the draft (draft-ietf-mobileip-reg-tunnel-02.txt) does not have these new messages. 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). 2. What is the implementation of the current version of the Draft (not the previous versions)? Thanks Gopal From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 03:40: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 DAA04270 for ; Wed, 11 Oct 2000 03:40:39 -0400 (EDT) Received: from standards (47.234.32.16:3404) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA143D@standards.nortelnetworks.com>; Wed, 11 Oct 2000 3:23:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 44995 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 03:23:48 -0400 Received: from stargate.ipunplugged.com (195.42.212.161:23122) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA143B@standards.nortelnetworks.com>; Wed, 11 Oct 2000 3:23:48 -0400 Received: from FREDRIKJPC ([192.168.4.218]) by stargate.ipunplugged.com (8.9.3/8.9.3) with SMTP id JAA26883 for ; Wed, 11 Oct 2000 09:36:48 +0200 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 Message-ID: Date: Wed, 11 Oct 2000 09:40:11 +0300 Reply-To: Fredrik Johansson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fredrik Johansson Subject: Re: [MOBILE-IP] draft-calhoun-diameter-mobileip-10.txt and existing authorization infrastructures To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <6D1A8E7871B9D211B3B00008C7490AA504E622FA@treis03nok> Content-Transfer-Encoding: 7bit Henry, see comments below, /Fredrik > -----Original Message----- > From: IP Routing for Wireless/Mobile Hosts (mobile-ip) > [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Henry > Haverinen > Sent: den 10 oktober 2000 16:04 > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] draft-calhoun-diameter-mobileip-10.txt and existing > authorization infrastructures > > > Hi folks, > > For those that are interested in MIP/AAA issues, please have > a look at the attached message, which I sent to this mailing > list a week ago. Any comments most welcome! > > Regards, > Henry > > > -----Original Message----- > > From: EXT Henry Haverinen [mailto:henry.haverinen@NOKIA.COM] > > Sent: 04. October 2000 15:31 > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: [MOBILE-IP] The use of existing authorization infrastructures > > with Mobile IP/ AAA > > > > > > Hi all, > > > > In summary, I propose the following additions to > > draft-calhoun-diameter-mobileip-10.txt in this mail. > > > > 1. Two new rules for FA behavior when receiving the AMA > > Command in response to the AMR Command: > > > > a) If the AMA Command doesn't contain a MIP-Reg-Reply AVP, > > the FA must forward the Reg.Request in question > > to the HA itself. How will the foreign agent know the address of the home agent, MIP/AAA enables dynamic assignment of home agent, thus the home agent field in the registration request may be set to 0.0.0.0 > > b) If the AMA Command includes the Result-Code AVP > > set to an error, the FA sends the MN a Reg.Reply with an > > error code but nevertheless includes any AAA or key > > distribution extensions from the AMA Command. > > > > 2. One new rule for HA behaviour: > > > > If the HA receives a Registration Request that contains > > the MN-AAA Authentication extension, either relayed by a > > FA or directly from a MN that is registering a co-located > > care-of address, the HA may issue the AMR Command in order > > to authorize the Reg.Request. The AMR Command includes some > > new flag which tells the AAA server that it does not have to > > contact the home agent, and that the request came directly > > from the home agent. > > > > --- > > > > The draft draft-haverinen-mobileip-gsmsim-00.txt describes how the > > existing GSM authorization infrastructure can be leveraged to achieve > > mobile user authorization for Mobile IP. The idea is not to use the > > GSM radio access technology, but to show how GSM SIM authorization > > could be used for Mobile IP authorization over any link layer, for > > example on WLAN hot spots. I'm writing a new revision of the draft > > which will fix the issues discussed on this mailing list and make the > > protocol to use the Mobile IP AAA extensions, so that the mobility > > agents don't need to be GSM SIM aware. > > > > The general model of leveraging an existing large scale > > authorization/charging infrastructure is very important because > > building new authorization infrastructures from scratch is hard: > > getting the necessary contracts and agreements in place takes effort > > and time. GSM authorization infrastructure is just one example of > > an existing large scale authorization infrastructure. Another such > > global infrastructure is the credit-card infra: e.g., consider > > the following scenario: I travel to a new location, pay the local > > ISP using my credit card, and continue to use Mobile IP with an HA > > in my home ISP. > > > > In my opinion, any MIP/AAA proposal should be able to easily support > > use of existing authorization infrastructures because it will greatly > > speed up deployment of Mobile IP. However, the current MIP/AAA drafts > > (e.g., draft-calhoun-diameter-mobileip-10.txt) have a couple of > > assumptions that do not support such authorization. The important > > aspect is that when existing authorization infrastructures are used, > > HA and AAAH are not necessarily under the same administrative control, > > and are not co-located. They are probably not even close to each > > other. > > > > Let's use the term AAAH to denote the AAA server that can authorize > > the user, and probably charge/bill the user where necessary. In the > > GSM SIM case, the AAAH is the Authentication Centre (AuC) which > > resides deep inside the GSM network. > > > > The foreign domain may have a local AAA network which includes a AAA > > server that has an interface to the GSM network. In this case, the > > local AAA network is able to reach the AAAH but the AAA network isn't > > able to reach the home agent, as the current MIP/AAA drafts assume. > > Suppose that a FA issues the DIAMETER AA-Mobile-Node-Request (AMR) > > Command to authorize a Registration Request that uses GSM SIM. The > > current view is that the the response from AAA (AA-Mobile-Node-Answer, > > AMA Command) includes the Registration Reply from the HA in a > > MIP-Reg-Reply AVP, which isn't possible in this case. > > > > One way to support such authorization would be to add a new rule to > > the operation of the FA: if the response from the AAA doesn't contain > > the Registration Reply, the FA must forward the request to the HA > > itself. > > > > Besides the reachability of the HA through the AAA network, > > the GSM SIM > > authorization breaks another assumption. A mobile node that > > is using GSM SIM is not able to provide the visited domain with > > complete yet unforgeable credentials without ever having been in touch > > with its home domain, as required in > > draft-ietf-mobileip-aaa-reqs-04.txt. > > This is because GSM SIM requires true challenge/response > > authentication > > where AAAH generates the challenge. In other words, it takes two round > > trips to authorize the MN. The AAA response in the first round trip > > contains the challenge. The result code in the response indicates that > > the user was not authorized. > > > > True challenge/response could be supported by adding another > > new rule to the operation of the FA: if the AAA responds to the > > FA's authorization request with an error, the FA sends the MN a > > Reg.Reply with an error code but nevertheless includes any AAA or key > > distribution extensions from the AAA response. These > > extensions contain > > the challenge. The MN is now able to send another Reg.Request > > for which > > the authorization will be successful. > > > > The same approach can also be used to for authorization in the home > > domain. Both HA and FA can use the same AAAH (located elsewhere) for > > authorizing the mobile user. > > > > The HA may receive a Reg.Request (from a co-located MN or a FA) that > > contains the MN-AAA Authentication extension. The HA could then pass > > the request to the AAA network, for example with the DIAMETER AMR > > Command, and the AAA network would respond with the AMA command, using > > the AAAH on the GSM network. Here we probably need a new flag > > in the AAA > > request that tells the AAA server that it does not have to contact the > > home agent, and that the request came directly from the home agent. > > Why not go through a local AAA which may provide the AAAH with the Foreign-Home-Agent-Available AVP, the AAAH can then authenticate the user and its a policy decision in the AAAH to allow the AAA in the local network to provide a HA, thus no need for the AAAH to contact a HA. So the mechanism is available today without any modifications to the draft. Regards /Fredrik > > > > Regards, > > Henry > > > > P.S. I'd like to acknowledge that Asokan (n.asokan@nokia.com) > > has contributed a lot in these ideas and in this mail. Many thanks! > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 05:31: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 FAA05124 for ; Wed, 11 Oct 2000 05:31:24 -0400 (EDT) Received: from standards (47.234.32.16:1868) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA14CD@standards.nortelnetworks.com>; Wed, 11 Oct 2000 5:14:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45182 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 05:14:34 -0400 Received: from mgw-x3.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA14CB@standards.nortelnetworks.com>; Wed, 11 Oct 2000 5:14:33 -0400 Received: from esebh01nok.ntc.nokia.com (esebh01nok.ntc.nokia.com [131.228.118.150]) by mgw-x3.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e9B9TKB05659 for ; Wed, 11 Oct 2000 12:29:20 +0300 (EET DST) Received: by esebh01nok with Internet Mail Service (5.5.2652.78) id <4V862BNJ>; Wed, 11 Oct 2000 12:24:34 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <6D1A8E7871B9D211B3B00008C7490AA504E622FC@treis03nok> Date: Wed, 11 Oct 2000 12:24:31 +0300 Reply-To: henry.haverinen@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Henry Haverinen Subject: Re: [MOBILE-IP] draft-calhoun-diameter-mobileip-10.txt and existi ng authorization infrastructures To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Fredrik, Thanks for your comments. Please see my notes below. > > > a) If the AMA Command doesn't contain a MIP-Reg-Reply AVP, > > > the FA must forward the Reg.Request in question > > > to the HA itself. > > How will the foreign agent know the address of the home agent, MIP/AAA > enables dynamic assignment of home agent, thus the home agent > field in the > registration request may be set to 0.0.0.0 If the MN doesn't know its home agent and sets the home agent field to 0.0.0.0 or 255.255.255.255, then this rule cannot be applied. This rule doesn't break dynamic home agent assignment, but it can be useful when the MN already knows its HA. Either a home agent has been assigned for the MN with an earlier registration (perhaps through another access network), or the MN is statically configured with the address of the home agent. Suppose that a MN is assigned a HA though the first network it visits. Perhaps the first network assigns the HA, or the first network has AAA connectivity to the user's corporate network which assigns the HA. Suppose that the MN then moves to another network, and the AAA cloud of the second access network is isolated from the HA, for example because the second network only has a backend GSM authentication server. In this case, a FA on the second access network could authorize the Reg.Request using its local AAA, and then apply the rule above and forward the request to the HA. > > > The HA may receive a Reg.Request (from a co-located MN or > a FA) that > > > contains the MN-AAA Authentication extension. The HA > could then pass > > > the request to the AAA network, for example with the DIAMETER AMR > > > Command, and the AAA network would respond with the AMA > command, using > > > the AAAH on the GSM network. Here we probably need a new flag > > > in the AAA > > > request that tells the AAA server that it does not have > to contact the > > > home agent, and that the request came directly from the > home agent. > > > > > Why not go through a local AAA which may provide the AAAH with the > Foreign-Home-Agent-Available AVP, the AAAH can then > authenticate the user > and its a policy decision in the AAAH to allow the AAA in the > local network > to provide a HA, thus no need for the AAAH to contact a HA. > So the mechanism > is available today without any modifications to the draft. There is no mechanism available for the case that the MN already has a HA which isn't reachable by the AAA of the visited network. The Foreign-Home-Agent-Available AVP doesn't help here, although it can be used to assign the HA in the beginning. Regards, Henry From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 07:08:28 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 HAA06394 for ; Wed, 11 Oct 2000 07:08:28 -0400 (EDT) Received: from standards (47.234.32.16:1553) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1599@standards.nortelnetworks.com>; Wed, 11 Oct 2000 6:51:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45442 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 06:51:23 -0400 Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA158E@standards.nortelnetworks.com>; Wed, 11 Oct 2000 6:41:23 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id DAA23554 for ; Wed, 11 Oct 2000 03:56:11 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id DAA06894 for ; Wed, 11 Oct 2000 03:56:10 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r3.mot.com with ESMTP for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 05:55:57 -0500 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id MAA23258 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM.DELIVER; Wed, 11 Oct 2000 12:56:07 +0200 (METDST) Received: from scooter.crm.mot.com (petrescu@riri.crm.mot.com [140.101.173.128]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id MAA23166 for ; Wed, 11 Oct 2000 12:56:06 +0200 (METDST) References: <200010042150.OAA21514@nasnfs.eng.sun.com> <39E38BD0.937CC926@cc.hut.fi> Lines: 41 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: Date: Wed, 11 Oct 2000 12:56:05 +0200 Reply-To: petrescu@acm.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Alex Petrescu Subject: Re: [MOBILE-IP] MIP implementation !!! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Tom K. =?iso-8859-1?q?Weckstr=F6m?="'s message of "Wed, 11 Oct 2000 00:36:16 +0300" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA06394 Mee too, I've compiled and I'm maintaining a sort of list of mobile ipv6 implementations. Here it is. Mobile IPv6 implementations --------------------------- KAME -bsd-ish. -Mobile-IPv6 code from Ericsson. -draft 09. INRIA HMIP -Hierarchical Mobile IPv6. -FreeBSD and Francis Dupont's IPv6 stack. -draft 09. MONARCH -bsd-ish. -1997. -draft 03. MICROSOFT RESEARCH -Windows. -partial IPv6 mobility support. NUS (National Univ of Singapore) -linux. LANCASTER UNIVERSITY -linux -draft-ietf-mobileip-ipv6-05 -Stefan Schmid, sschmid@COMP.LANCS.AC.UK. MIPL at hut.fi -linux 2.4.0 -Sami Kivisaari, Niklas Kämpe, Juha Mynttinen, Toni Nykänen, Henrik Petander and Antti Tuominen -draft-12. FRANCIS DUPONT -has a mipv6 implementation based on his ipv6 stack. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 09:44: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 JAA10697 for ; Wed, 11 Oct 2000 09:44:34 -0400 (EDT) Received: from standards (47.234.32.16:1181) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA16DF@standards.nortelnetworks.com>; Wed, 11 Oct 2000 9:27:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45895 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 09:27:16 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA16DD@standards.nortelnetworks.com>; Wed, 11 Oct 2000 9:27:15 -0400 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA28611; Wed, 11 Oct 2000 07:42:01 -0600 (MDT) 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 GAA18301; Wed, 11 Oct 2000 06:42:00 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id GAA20971; Wed, 11 Oct 2000 06:41:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Wed, 11 Oct 2000 06:39:45 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA X-To: Fredrik Johansson To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" Well, perhaps I am missing something here, but I really don't see the need for challenge/response support in a co-located MN. The challenge is useful to FAs to provide replay protection. Since MNs already have a replay protection scheme with the Home Agent, the challenge doesn't provide anything additional. PatC > Hi, > > the mobile node generates the challenge and send the request to the home > agent. The home agent will then include the same challenge in the > registration reply, is it up to the implementation of the co-located foreign > agent to remove the challenge before giving it to the mobile client so it is > not misstaken for a new challenge that can be sent in the registration reply > for use in the next registration? > > /Fredrik > > > -----Original Message----- > > From: IP Routing for Wireless/Mobile Hosts (mobile-ip) > > [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Woo-June Kim > > Sent: den 6 oktober 2000 17:28 > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA > > > > > > Fredrik, > > > > The mobile node itself just generates a random number to use as > > the challenge. The response can only be correctly calculated by > > the mobile if it knows the correct key and algorithm. The AAA is > > simply using this fact to check the mobile's identity in a > > round-about manner. The challenge value itself is not something > > that must be generated in some special manner. > > > > cheers > > > > >BlankHi > > > > > >I have a question concerning how Challenge / Response is supposed to work > > >when a mobile node registers using a co-located foreign agent. > > > > > >Since the mobile node does not receive an advertisement with a challenge > > >from a FA it cannot calculate a response to be used in a MN-AAA > > >Authentication extension, i.e., the Home Agent cannot use a > > Radius server to > > >authenticate the MN. > > > > > >Have there been any thoughts in this area, or perhaps a solution in an > > >earlier thread that I've missed? Thankful for any pointers. > > > > > >Regards > > >/Fredrik > > >----------------------------------------- > > >Fredrik Johansson > > > > > >W: +46 (0)8 725 5916 > > >M: +46 (0)70 786 5035 > > >mailto:Fredrik.Johansson@ipunplugged.com > > >http://www.ipunplugged.com > > > > > > > > > > > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 10:02: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 KAA11067 for ; Wed, 11 Oct 2000 10:02:37 -0400 (EDT) Received: from standards (47.234.32.16:1181) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA173D@standards.nortelnetworks.com>; Wed, 11 Oct 2000 9:45:47 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 46018 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 09:45:47 -0400 Received: from stargate.ipunplugged.com (195.42.212.161:23647) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA173B@standards.nortelnetworks.com>; Wed, 11 Oct 2000 9:45:46 -0400 Received: from FREDRIKJPC ([192.168.4.218]) by stargate.ipunplugged.com (8.9.3/8.9.3) with SMTP id PAA30264; Wed, 11 Oct 2000 15:58:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-ID: Date: Wed, 11 Oct 2000 16:01:59 +0300 Reply-To: Fredrik Johansson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fredrik Johansson Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit Hi Pat, It was not to provide replay protection but to enable the home agent to authenticate the user towards a Radius server using CHAP. In the radius request a challenge and a response is needed. Using the MN-HA Authentication extension does not provide a challenge. Or is there another way of doing this? /Fredrik > -----Original Message----- > From: pcalhoun@eng.sun.com [mailto:Pat.Calhoun@Eng.Sun.COM] > Sent: den 11 oktober 2000 16:40 > To: Fredrik Johansson > Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA > > > Well, perhaps I am missing something here, but I really don't see > the need for > challenge/response support in a co-located MN. The challenge is > useful to FAs > to provide replay protection. Since MNs already have a replay protection > scheme with the Home Agent, the challenge doesn't provide > anything additional. > > PatC > > Hi, > > > > the mobile node generates the challenge and send the request to the home > > agent. The home agent will then include the same challenge in the > > registration reply, is it up to the implementation of the > co-located foreign > > agent to remove the challenge before giving it to the mobile > client so it is > > not misstaken for a new challenge that can be sent in the > registration reply > > for use in the next registration? > > > > /Fredrik > > > > > -----Original Message----- > > > From: IP Routing for Wireless/Mobile Hosts (mobile-ip) > > > [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of > Woo-June Kim > > > Sent: den 6 oktober 2000 17:28 > > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA > > > > > > > > > Fredrik, > > > > > > The mobile node itself just generates a random number to use as > > > the challenge. The response can only be correctly calculated by > > > the mobile if it knows the correct key and algorithm. The AAA is > > > simply using this fact to check the mobile's identity in a > > > round-about manner. The challenge value itself is not something > > > that must be generated in some special manner. > > > > > > cheers > > > > > > >BlankHi > > > > > > > >I have a question concerning how Challenge / Response is > supposed to work > > > >when a mobile node registers using a co-located foreign agent. > > > > > > > >Since the mobile node does not receive an advertisement with > a challenge > > > >from a FA it cannot calculate a response to be used in a MN-AAA > > > >Authentication extension, i.e., the Home Agent cannot use a > > > Radius server to > > > >authenticate the MN. > > > > > > > >Have there been any thoughts in this area, or perhaps a > solution in an > > > >earlier thread that I've missed? Thankful for any pointers. > > > > > > > >Regards > > > >/Fredrik > > > >----------------------------------------- > > > >Fredrik Johansson > > > > > > > >W: +46 (0)8 725 5916 > > > >M: +46 (0)70 786 5035 > > > >mailto:Fredrik.Johansson@ipunplugged.com > > > >http://www.ipunplugged.com > > > > > > > > > > > > > > > > > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 10:14: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 KAA11310 for ; Wed, 11 Oct 2000 10:14:01 -0400 (EDT) Received: from standards (47.234.32.16:1181) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1767@standards.nortelnetworks.com>; Wed, 11 Oct 2000 9:50:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 46070 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 09:50:02 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1765@standards.nortelnetworks.com>; Wed, 11 Oct 2000 9:50:01 -0400 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA09908; Wed, 11 Oct 2000 08:04:47 -0600 (MDT) 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 HAA20834; Wed, 11 Oct 2000 07:04:47 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA21177; Wed, 11 Oct 2000 07:04:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Wed, 11 Oct 2000 07:02:25 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA X-To: Fredrik Johansson To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" Ahh... sorry. I thought your question was in regards to the challenge extension, and not the MN-AAA authentication extension. In any case, for the latter, it does require that the former be present, and the mobile can generate its own challenge (hmmmm.... quite insecure, isn't it). I am also tempted to say that the Home Agent should return an new error code with a challenge value, and force the Mobile Node to re-register. Unfortunately, the soon to be RFC doesn't discuss co-location. PatC > Hi Pat, > > It was not to provide replay protection but to enable the home agent to > authenticate the user towards a Radius server using CHAP. In the radius > request a challenge and a response is needed. Using the MN-HA > Authentication extension does not provide a challenge. > > Or is there another way of doing this? > > /Fredrik > > > -----Original Message----- > > From: pcalhoun@eng.sun.com [mailto:Pat.Calhoun@Eng.Sun.COM] > > Sent: den 11 oktober 2000 16:40 > > To: Fredrik Johansson > > Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA > > > > > > Well, perhaps I am missing something here, but I really don't see > > the need for > > challenge/response support in a co-located MN. The challenge is > > useful to FAs > > to provide replay protection. Since MNs already have a replay protection > > scheme with the Home Agent, the challenge doesn't provide > > anything additional. > > > > PatC > > > Hi, > > > > > > the mobile node generates the challenge and send the request to the home > > > agent. The home agent will then include the same challenge in the > > > registration reply, is it up to the implementation of the > > co-located foreign > > > agent to remove the challenge before giving it to the mobile > > client so it is > > > not misstaken for a new challenge that can be sent in the > > registration reply > > > for use in the next registration? > > > > > > /Fredrik > > > > > > > -----Original Message----- > > > > From: IP Routing for Wireless/Mobile Hosts (mobile-ip) > > > > [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of > > Woo-June Kim > > > > Sent: den 6 oktober 2000 17:28 > > > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA > > > > > > > > > > > > Fredrik, > > > > > > > > The mobile node itself just generates a random number to use as > > > > the challenge. The response can only be correctly calculated by > > > > the mobile if it knows the correct key and algorithm. The AAA is > > > > simply using this fact to check the mobile's identity in a > > > > round-about manner. The challenge value itself is not something > > > > that must be generated in some special manner. > > > > > > > > cheers > > > > > > > > >BlankHi > > > > > > > > > >I have a question concerning how Challenge / Response is > > supposed to work > > > > >when a mobile node registers using a co-located foreign agent. > > > > > > > > > >Since the mobile node does not receive an advertisement with > > a challenge > > > > >from a FA it cannot calculate a response to be used in a MN-AAA > > > > >Authentication extension, i.e., the Home Agent cannot use a > > > > Radius server to > > > > >authenticate the MN. > > > > > > > > > >Have there been any thoughts in this area, or perhaps a > > solution in an > > > > >earlier thread that I've missed? Thankful for any pointers. > > > > > > > > > >Regards > > > > >/Fredrik > > > > >----------------------------------------- > > > > >Fredrik Johansson > > > > > > > > > >W: +46 (0)8 725 5916 > > > > >M: +46 (0)70 786 5035 > > > > >mailto:Fredrik.Johansson@ipunplugged.com > > > > >http://www.ipunplugged.com > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 13:55: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 NAA16298 for ; Wed, 11 Oct 2000 13:55:18 -0400 (EDT) Received: from standards (47.234.32.16:1176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1950@standards.nortelnetworks.com>; Wed, 11 Oct 2000 13:31:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0491 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 13:31:26 -0400 Received: from catarina.usc.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA194E@standards.nortelnetworks.com>; Wed, 11 Oct 2000 13:31:26 -0400 Received: from localhost (meeta@localhost) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA07876; Wed, 11 Oct 2000 10:46:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Wed, 11 Oct 2000 10:46:10 -0700 Reply-To: Meeta Sharma Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Meeta Sharma Subject: Re: [MOBILE-IP] Registration Reply X-To: "Gowri S.Makineni" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <3.0.5.32.20001010090725.0132b100@hub.ecutel.com> hi, thanks for this reply.. i have another question.. The HA agent might only have the option of supporting one binding..and then if it gets a req(i+1)..and it has already granted req(i) for the same binding then would it reject(i+1)? also, then if it rejects then the tunnel would not be complete..? I am wrong somewhere in my conclusion? Thanks, Regards, -Meeta On Tue, 10 Oct 2000, Gowri S.Makineni wrote: > At 04:08 PM 10/9/00 -0700, Meeta Sharma wrote: > >Hi all, > >I was looking into mobile ip(rfc 2002) for one of my projects. I had a > >question: > >What happens when the registration reply(i) from foreign agent to mobile > >node is delayed? It can happen that the timer at the mobile node expires > >and that the mobile node sends another request(i+1)..but then it gets a > >reply(i) would it accept it or reject it? > > If the timer expires at the mobile node, it sends another registration > request, > and discards replies to the previous requests that it sent. > > >Also, what if Foreign agent sees that it had sent a reply for (i) and now > >is getting a request(i+1) then would it discard it or send the reply back > >again? without going to the home agent? > > The foreign agent forwards all "proper" requests that it receives and forwards > them to the respective agents. Your (i+1) request is also forwarded to your > HA. > The replies of i and i+1 requests from the HA would be sent to the mobile > node provided time out does not occur at the FA. > > >I am a little confused and maybe the answers would help me in my model. > >Thanks, > >Regards, > >Meeta > > > Hope that helps. > GSM > Gowri S. Makineni > Sr. Systems Engineer, > Ecutel > (703)354-4140 X-110 > ---------------------------------------------------------- > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 14:08: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 OAA16672 for ; Wed, 11 Oct 2000 14:08:32 -0400 (EDT) Received: from standards (47.234.32.16:1150) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA19D8@standards.nortelnetworks.com>; Wed, 11 Oct 2000 13:51:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0178 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 13:51:35 -0400 Received: from qhars002.nortel.com (47.101.112.102:39298) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA19D6@standards.nortelnetworks.com>; Wed, 11 Oct 2000 13:51:35 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Wed, 11 Oct 2000 19:05:51 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Wed, 11 Oct 2000 14:05:34 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id <44WQ7SN7>; Wed, 11 Oct 2000 14:05:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C033AD.D3719910" Message-ID: Date: Wed, 11 Oct 2000 14:05:23 -0400 Reply-To: Abderrahmane Lakas Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Abderrahmane Lakas Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt X-To: "Casati, Alessio (Alessio)" 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_01C033AD.D3719910 Content-Type: text/plain; charset="iso-8859-1" Alessio, Consider the actual case of dynamic QoS provisioning: In mobile access networks, traffic sources are either unknown in advance, or for scalability reason, the provisioning is done only when the MN registers with the network. For that the PDP, for example, may use the NAI extension to retrieve the MN's QoS profile. But, we should not limit ourselves only to the extensions that are defined. In general, the mobility raises new questions on how MN and mobility agents should operate with regards to QoS management and enforcement. COPS-MIP provides a flexible mechanism through which MIP extensions are exchanged between the PEP and the PDP, in order to decide the modes in which the MN and the mobility agents should operate. For example, consider the situation where the MN moves to a new location (within the same or to a different foreign network), with active QoS sessions. When registering, MN may express preferences as to whether the granted QoS be dropped (hard requirements), or downgraded (adaptive QoS) if the capabilities (wireless link + network) at the new location are limited. Hope these examples help understand why we need a new COPS client to handle policy management for mobile IP. - Abderrahmane -----Original Message----- From: Casati, Alessio (Alessio) [mailto:acasati@LUCENT.COM] Sent: Monday, October 09, 2000 5:40 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt > Abderrahmane; > First off, thanks for your answer. > Alessio, > > First let me say that I agree this section might have introduced some > confusion. It is only meant to capture the requirements of message > ordering for authentication as defined by mobile IP, in case the PDP is > involved in "handling" authentication extensions. The PDP's involvement > may be, for example, in acting as an "attendant" (on behalf of the > mobility agent) to the AAA server before making any policy decision. > > I agree with you the current text may have generated some confusion. I would suggest, if you have time, you provide an applicability example, based on current mobile IP extension, of the proposed COPS-MIP client. This would be very helpful to fully understand your proposal and to let the Mobile IP list to evaluate it and provide useful comments. > As I stated it in my first email, during the writing of this draft, it was > not clear (still is not) for us how AAA would interact with a policy > server to handle common situations. But one should agree that it is hard > to see that section 4 describes any AAA mechanism, or explains the AAA > model for MIP. > I agree that the section does not describe an AAA model for MIP. In fact, the AAA model for MIP is well defined, and this proposal would seem to try to comply with it. That's why there are voices expressing the worry that this would introduce some overlap/conflict with the work currently ongoing in the AAA WG (where after two year a protocol has been selected to base AAA for network access on). Your text hints to the possibility to use the PDP to perform authentication. We need to have a clear understanding of this and other applicability cases of your proposal. You would probably have to bring to the list cases (or a single case) supporting the necessity of your proposal. Could you please do that as soon as you have some leftover time? I'd wholeheartedly support any proposals of necessary building blocks to support policy control in conjunction with mobile IP. I have to understand whether this is one such building block we are missing. Thanks alessio ------_=_NextPart_001_01C033AD.D3719910 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] FW: I-D = ACTION:draft-jaseem-rap-cops-mip-00.txt

Alessio,

Consider the actual case of dynamic QoS provisioning: = In mobile access networks, traffic sources are either unknown in = advance, or for scalability reason, the provisioning is done only when = the MN registers with the network. For that the PDP, for example, may = use the NAI extension to retrieve the MN's QoS profile.

But, we should not limit ourselves only to the = extensions that are defined. In general, the mobility raises new = questions on how MN and mobility agents should operate with regards to = QoS management and enforcement. COPS-MIP provides a flexible mechanism = through which MIP extensions are exchanged between the PEP and the PDP, = in order to decide the modes in which the MN and the mobility agents = should operate. For example, consider the situation where the MN moves = to a new location (within the same or to a different foreign network), = with active QoS sessions. When registering, MN may express preferences = as to whether the granted QoS be dropped (hard requirements), or = downgraded (adaptive QoS) if the capabilities (wireless link + network) = at the new location are limited.

Hope these examples help understand why we need a new = COPS client to handle policy management for mobile IP.

- Abderrahmane

-----Original Message-----
From: Casati, Alessio (Alessio) [mailto:acasati@LUCENT.COM]=
Sent: Monday, October 09, 2000 5:40 AM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP] FW: I-D = ACTION:draft-jaseem-rap-cops-mip-00.txt


> Abderrahmane;
>
First off, thanks for your answer.

> Alessio,
>
> First let me say that I agree this section = might have introduced some
> confusion. It is only meant to capture the = requirements of message
> ordering for authentication as defined by = mobile IP, in case the PDP is
> involved in "handling" authentication = extensions. The PDP's involvement
> may be, for example, in acting as an = "attendant" (on behalf of the
> mobility agent) to the AAA server before making = any policy decision.
>
>
I agree with you the current text may have generated = some confusion.
I  would suggest, if you have time,
you provide an applicability example, based on = current
mobile IP extension, of the proposed COPS-MIP = client.
This would be very helpful to fully understand your = proposal
and to let the Mobile IP list to evaluate it and = provide
useful comments.


> As I stated it in my first email, during the = writing of this draft, it was
> not clear (still is not) for us how AAA would = interact with a policy
> server to handle common situations. But one = should agree that it is hard
> to see that section 4 describes any AAA = mechanism, or explains the AAA
> model for MIP.
>
I agree that the section does not describe an AAA = model for MIP.
In fact, the AAA model for MIP is well defined, and = this proposal would seem
to
try to comply with it. That's why there are voices = expressing the worry
that this would introduce some overlap/conflict with = the work currently
ongoing in
the AAA WG (where after two year a protocol has been = selected
to base AAA for network access on).

Your text hints to the possibility to use the PDP to = perform
authentication. We need to have a clear = understanding of this and other
applicability cases of your proposal. You would = probably have to
bring to the list cases (or a single case) = supporting the necessity of your
proposal. Could you please do that as soon as you = have some
leftover time?  I'd wholeheartedly support any = proposals of
necessary building blocks to support policy control = in conjunction with
mobile IP. I have to understand whether this is one = such building block
we are missing.

Thanks


alessio

------_=_NextPart_001_01C033AD.D3719910-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 14:31: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 OAA17355 for ; Wed, 11 Oct 2000 14:31:17 -0400 (EDT) Received: from standards (47.234.32.16:1150) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1A8F@standards.nortelnetworks.com>; Wed, 11 Oct 2000 14:14:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0405 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 14:14:27 -0400 Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1A8D@standards.nortelnetworks.com>; Wed, 11 Oct 2000 14:14:26 -0400 Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e9BITAK07464; Wed, 11 Oct 2000 21:29:11 +0300 (EET DST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Wed, 11 Oct 2000 13:29:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E3D9@daeis07nok> Date: Wed, 11 Oct 2000 13:25:41 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] Spam problems on the list X-To: Steven.Glass@east.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Steve, I have absolutely no issues about doing some kind of filtering to avoid some of the junk that seems to be creeping in on this mailing list. However the rule for the list(s) is to be able to allow anyone to be able to post to the list, meaning allowing someone who has never registered with the Mobile IP list to be able to post. -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 14:41: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 OAA17745 for ; Wed, 11 Oct 2000 14:41:59 -0400 (EDT) Received: from standards (47.234.32.16:1150) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1AEB@standards.nortelnetworks.com>; Wed, 11 Oct 2000 14:20:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0527 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 14:20:58 -0400 Received: from hub.ecutel.com (ecutel.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1AE9@standards.nortelnetworks.com>; Wed, 11 Oct 2000 14:20:57 -0400 Received: from 192.168.50.149 by smtp.ecutel.com Wed, 11 Oct 2000 14:47:13 -0500 Received: from gsm [192.168.50.6] by hub.ecutel.com (SMTPD32-5.05) id AA5017C90124; Wed, 11 Oct 2000 15:06:56 -0400 X-Sender: makineni@hub.ecutel.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) References: <3.0.5.32.20001010090725.0132b100@hub.ecutel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.5.32.20001011143958.0130f320@hub.ecutel.com> Date: Wed, 11 Oct 2000 14:39:58 -0500 Reply-To: "Gowri S.Makineni" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Gowri S.Makineni" Subject: Re: [MOBILE-IP] Registration Reply X-To: Meeta Sharma To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: At 10:46 AM 10/11/00 -0700, Meeta Sharma wrote: >hi, >thanks for this reply.. >i have another question.. >The HA agent might only have the option of supporting one binding..and >then if it gets a req(i+1)..and it has already granted req(i) for the same >binding then would it reject(i+1)? >also, then if it rejects then the tunnel would not be complete..? >I am wrong somewhere in my conclusion? The registration gets updated, since the shuttle uses the same care of address of the FA. The HA does not distinguish between the request of i+1 or i+10. If you want multiple bindings the shuttle should specify that it needs bindings and turn the 'S' bit flag ON in the registration request or else the information at the HA is just updated for that shuttle. By the definition of bindings means that the shuttle has multiple care of addresses and it is registering all those addresses with the HA. -GSM >Thanks, >Regards, >-Meeta Gowri Shankar Makineni Sr. Systems Engineer, Ecutel (703)354-4140 X-110 ---------------------------------------------------------- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 14:59: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 OAA18187 for ; Wed, 11 Oct 2000 14:59:54 -0400 (EDT) Received: from standards (47.234.32.16:1150) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1BD5@standards.nortelnetworks.com>; Wed, 11 Oct 2000 14:43:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0765 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 14:43:13 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1BA6@standards.nortelnetworks.com>; Wed, 11 Oct 2000 14:33:12 -0400 Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Wed Oct 11 14:46:19 EDT 2000 Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by grubby; Wed Oct 11 14:46:18 EDT 2000 Received: from research.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by mail1.pa.bell-labs.com (Mirapoint) with ESMTP id AAV28765 (AUTH gja); Wed, 11 Oct 2000 11:46:16 -0700 (PDT) X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E3D9@daeis07nok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39E4B68B.BBCCC1A0@research.bell-labs.com> Date: Wed, 11 Oct 2000 11:50:51 -0700 Reply-To: Grenville Armitage Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies Subject: Re: [MOBILE-IP] Spam problems on the list X-To: Basavaraj.Patil@nokia.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Basavaraj Patil wrote: [..] > However the rule for the list(s) is to be able to allow > anyone to be able to post to the list, meaning allowing someone > who has never registered with the Mobile IP list to be able to post. I dont see the conclusion follows directly from the stated goal. Introducing a scheme whereby first-time posters must validate that they are posting from a marginally long-lived account doesn't prevent "anyone" from posting, it just prevents "once off" accounts from posting. cheers, gja From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 15:11: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 PAA18730 for ; Wed, 11 Oct 2000 15:11:01 -0400 (EDT) Received: from standards (47.234.32.16:1150) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1C3B@standards.nortelnetworks.com>; Wed, 11 Oct 2000 14:54:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0948 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 14:54:12 -0400 Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1C39@standards.nortelnetworks.com>; Wed, 11 Oct 2000 14:54:11 -0400 Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA09352 for ; Wed, 11 Oct 2000 15:09:01 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA09347 for ; Wed, 11 Oct 2000 15:09:00 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <4MGP0LNJ>; Wed, 11 Oct 2000 20:09:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <976F7C55E3B2D111A0720008C728549C04877384@en0060exch001u.uk.lucent.com> Date: Wed, 11 Oct 2000 20:08:58 +0100 Reply-To: "Casati, Alessio (Alessio)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Casati, Alessio (Alessio)" Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Abderrahmane, > Consider the actual case of dynamic QoS provisioning: In mobile access > networks, traffic sources are either unknown in advance, or for > scalability reason, the provisioning is done only when the MN registers > with the network. For that the PDP, for example, may use the NAI extension > to retrieve the MN's QoS profile. > I guess the (QoS) profile(s) is (are) downloaded from a HSS. I would say the AAA protocol could work fine as a carrier of any profile. It would be nice that all profiles were downloaded at registration time, so that there would be no roundtrips before taking any policy enforcement action. Now, let's suppose we download the profile(s) to a PDP, since the device the user is attached too has storage limitations (quite unlikely in cellular networks, but we don't want to limit the scope of the work to cellular systems). However, I see queries being directed to the PDP only if requests are incoming at times different from the registration. If so, those requests could include mobile IP extensions (if they are using mobile IP enhancements????) defined to comply with COPS-RSVP. And as such we wouldn't need to use any new COPS client. Besides, if the Qos signaling mechanism was RSVP, of course RSVP client would be used. If instead the QoS profile is is installed at registration time, then the FA could receive it and use it from the AAA client. How does it sound??? > For example, consider the situation where the MN moves to a new location > (within the same or to a different foreign network), with active QoS > sessions. When registering, MN may express preferences as to whether the > granted QoS be dropped (hard requirements), or downgraded (adaptive QoS) > if the capabilities (wireless link + network) at the new location are > limited. > I would support your proposal if I had in front of me facts, rather than forward looking statements. I have no clear understanding of this latter example operation in terms of mobile IP extensions usage (could RSVP or COPS RSVP be extended instead?) In fact, in the face of the previous scenario you have presented showing we need COPS-MIP, I was hopefully able to give a counter-example that makes it not necessary. Could we say that we may keep your proposal dormant until we know exactly the scope of its use? That is we have the extensions we want to use and determined the best way we want to use them ? This would be my stance for now. thanks alessio From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 15:44: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 PAA19802 for ; Wed, 11 Oct 2000 15:44:54 -0400 (EDT) Received: from standards (47.234.32.16:1150) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1CF5@standards.nortelnetworks.com>; Wed, 11 Oct 2000 15:28:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1177 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 15:28:10 -0400 Received: from quartz.airtouch.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1CF3@standards.nortelnetworks.com>; Wed, 11 Oct 2000 15:28:09 -0400 Received: from Notes.airtouch.com (ath-irv-smtp1.it.cl.airtouch.com [153.114.55.212]) by quartz.airtouch.com (8.8.8+Sun/8.8.8) with SMTP id MAA08133 for ; Wed, 11 Oct 2000 12:51:37 -0700 (PDT) Received: by Notes.airtouch.com(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id 88256975.006C2CCD ; Wed, 11 Oct 2000 12:41:33 -0700 X-Lotus-FromDomain: AIRTOUCH Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <88256975.006C2BAB.00@Notes.airtouch.com> Date: Wed, 11 Oct 2000 12:40:55 -0700 Reply-To: Bryan.Cook@NOTES.AIRTOUCH.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Bryan Cook Subject: Re: [MOBILE-IP] Registration Reply To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Greeting Mobile IP folks, I am very new to this list, so forgive me if my questions seems inappropriate. I work for a large cellular company (you might have heard of it). I am interested in the following: - What are currently the "hot points" surrounding Mobile IP, i.e. what broad topics are debated that still need resolved? - Are there any people out there (or groups) that are looking at Mobile IP specifically from a large cellular provider perspective? What topics bear the strongest relevance to this application? - Interoperability: Who is managing interop for large developers of Mobile IP products (Cisco, Nortel, Lucent, etc.) - What is the current status of the standard? I would certainly appreciate answers to these questions, or referals to sources of info if that is appropriate as well! Thanks much..... P.S. Count one more vote in favor of the tarring and feathering of spammers "Gowri S.Makineni" on 10/11/2000 12:39:58 PM Please respond to "Gowri S.Makineni" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Bryan Cook/Corporate/AirTouch) Subject: Re: [MOBILE-IP] Registration Reply At 10:46 AM 10/11/00 -0700, Meeta Sharma wrote: >hi, >thanks for this reply.. >i have another question.. >The HA agent might only have the option of supporting one binding..and >then if it gets a req(i+1)..and it has already granted req(i) for the same >binding then would it reject(i+1)? >also, then if it rejects then the tunnel would not be complete..? >I am wrong somewhere in my conclusion? The registration gets updated, since the shuttle uses the same care of address of the FA. The HA does not distinguish between the request of i+1 or i+10. If you want multiple bindings the shuttle should specify that it needs bindings and turn the 'S' bit flag ON in the registration request or else the information at the HA is just updated for that shuttle. By the definition of bindings means that the shuttle has multiple care of addresses and it is registering all those addresses with the HA. -GSM >Thanks, >Regards, >-Meeta Gowri Shankar Makineni Sr. Systems Engineer, Ecutel (703)354-4140 X-110 ---------------------------------------------------------- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 16:43:28 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 QAA21189 for ; Wed, 11 Oct 2000 16:43:28 -0400 (EDT) Received: from standards (47.234.32.16:1150) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1DA8@standards.nortelnetworks.com>; Wed, 11 Oct 2000 16:26:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1383 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 16:26:35 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1D95@standards.nortelnetworks.com>; Wed, 11 Oct 2000 16:16:34 -0400 Received: from purol.East.Sun.COM ([129.148.9.11]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA02620; Wed, 11 Oct 2000 13:31:23 -0700 (PDT) Received: from onion.east.sun.com (onion [129.148.174.110]) by purol.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id QAA11350; Wed, 11 Oct 2000 16:31:20 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Wed, 11 Oct 2000 16:31:13 -0400 Reply-To: Steven Glass - Solaris Software Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Steven Glass - Solaris Software Subject: Re: [MOBILE-IP] Spam problems on the list X-To: Basavaraj.Patil@NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E3D9@daeis07nok> > Steve, > > I have absolutely no issues about doing some kind of filtering to > avoid some of the junk that seems to be creeping in on this > mailing list. However the rule for the list(s) is to be able to allow > anyone to be able to post to the list, meaning allowing someone > who has never registered with the Mobile IP list to be able to post. > -Basavaraj I can appreciate this position, in spirit. The issue seems to be whether requiring subscription to post makes a list closed. I thought the IPNG WG had a 'subscribe to post' policy, but I may be mistaken (it wouldn't allow us to automatically impose such a policy, but if the WG decided it wanted to go that route, it would certainly be evidence to allow us to do so). An open or closed list (to me) has always been defined as who's allowed to subscribe. Since we allow anyone to subscribe, I think the list is open regardless of requiring subscription to post. I understand that there are those among us who want to be able to post without seeing every message, such as our IESG folks, and I don't want to exclude their postings, but they can be added as special cases to the posting rules - e.g. if (subscribed(fromAddr)) || (IsIESG(fromAddr)) { allow(); } else { devNull(); } Taking this to an extreme, we can also accomodate those who want to be able to post from multiple addresses w/o requiring them to subscribe both addresses, we just simply add a post-option to the list, that is have a post-list which is different from the distribution list. In IESG terms, this 'filtering' labels a list as "moderated." From http://www.ietf.org/IESG/STATEMENTS/moderated-lists.txt : IESG guidance on the moderation of IETF Working Group Mailing Lists ------------------------------------------------------------------- In some cases, it is necessary and appropriate to moderate IETF mailing lists. For example, moderation might be needed to control excessive spam, persistent off-topic postings, persistent personal attacks, etc. on mailing lists. The IESG has devised the following set of guidelines for the moderation of mailing lists. 1) The appropriate AD(s) must approve of a list being moderated. 2) The WG should be kept informed of a mailing list's moderation policy. For example, a message could be posted to the mailing list on a regular basis, or new members could be sent the policy as part of the welcome message when subscribing. 3) Messages should be accepted or rejected in whole; selective editing of messages to remove off-topic content is not permitted. 4) When rejecting a note, a note must be returned to the author with a short explanation. 5) Rejected notes should be saved for a reasonable period of time, so that there is a record in the event a dispute arises. 6) Items 3-5 apply to all manually rejected messages that require some thinking on the part of the moderator. They do not apply to obvious off-topic "make money fast" messages, or messages rejected through generic automated means (i.e., automated spam-filters on mailing list software). In item (2) I would opt for a policy-notice upon subscription. Note also that (it seems) 3-5 could be done automatically based on any policy the ADs allow (based on WG request/recommendation). I would presume it can include a 'subscription list' policy, if that's what the WG wishes to propose to the AD. Cheers, Steve From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 16:43: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 QAA21193 for ; Wed, 11 Oct 2000 16:43:28 -0400 (EDT) Received: from standards (47.234.32.16:1150) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1DAB@standards.nortelnetworks.com>; Wed, 11 Oct 2000 16:26:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1384 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 16:26:49 -0400 Received: from www.kochang-coh.ed.kyongnam.kr (211.34.200.1:1738) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1D96@standards.nortelnetworks.com>; Wed, 11 Oct 2000 16:16:48 -0400 Received: by www.kochang-coh.ed.kyongnam.kr id FAA0000005281; Thu, 12 Oct 2000 05:25:59 +0900 (KST) Received: from by datastre-5o7vdq with ESMTP; Wed, 11 Oct 2000 16:36:54 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <0000486d4103$0000325d$0000074b@> Date: Wed, 11 Oct 2000 16:36:46 -0400 Reply-To: jbswifty@EARTHLINK.NET Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: jbswifty@EARTHLINK.NET Subject: [MOBILE-IP] India ISP and Telcom ,Wall Streets next major growth 1867 X-To: "Undisclosed Recipients"@www.kochang-coh.ed.kyongnam.kr To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: quoted-printable The stock GOLX has penetrated the Telecommunications a= nd Internet market of India. This newly trading Company is the world's fir= st digital conglomerate with its high-speed broadband network, it is the m= ost comprehensive set of services available on the Internet today. Find ou= t why Global Crossing, Seimans, Nokia, MCI Worldcom, Phillips, has an inte= rest in GOLX...

Come Learn More
http://www.golx3.com4.ws/golx/




You were se= nt this message because your address is in our subscriber database. If you= wish to be removed, please reply here; http://www.golx3.com4.ws/golx/response.html and we will rem= ove you from our subscriber list. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 17:09: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 RAA21815 for ; Wed, 11 Oct 2000 17:09:10 -0400 (EDT) Received: from standards (47.234.32.16:1150) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1EBC@standards.nortelnetworks.com>; Wed, 11 Oct 2000 16:52:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1759 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 16:52:27 -0400 Received: from sj-msg-core-2.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1EBA@standards.nortelnetworks.com>; Wed, 11 Oct 2000 16:52:27 -0400 Received: from p7020-img-nt.cisco.com (sj-dial-1-91.cisco.com [171.68.179.92]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA04054; Wed, 11 Oct 2000 14:07:14 -0700 (PDT) X-Sender: fred@flipper X-Mailer: QUALCOMM Windows Eudora Version 5.0 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.0.0.25.2.20001011112214.01dc5470@flipper> Date: Wed, 11 Oct 2000 11:29:32 -0600 Reply-To: Fred Baker Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fred Baker Subject: Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup port in IPv6"draft] X-To: Glenn Morrow To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <36FA02BD7083D411BC9E0000F8073E438CEECC@crchy271.us.nortel. com> At 10:03 AM 10/10/00 -0500, Glenn Morrow wrote: >gm> I'm not so sure about the MAC address needing to match for all cases. >The standard first hop ingress filtering would work for the COA address >without any additional routes etc.. in the first hop router. Well, I mentioned MAC Address to IP Source Address mapping on the first routed hop because many of those are in fact on LANs and there is a correlation that can be checked. When the first routed hop is also a COA (or a designated address on the system, perhaps a loopback address, is a COA), it would be easy enough to add its own address to the list of acceptable mappings. My point here is that a common attack mode is that some system fabricates traffic as if from some other system. If the system is topologically distinct, an RPF check will catch it. If the other system is or appears to be on the same LAN, the RPF check will not. correlating MAC and IP Source Address should catch that. That said, obviously not all attachments are LAN attachments, and getting anything to happen universally is a nightmare. So for dial-up and related, one maybe could assume that only a small set of addresses are acceptable form the far end, and beyond that we're back to RPF checks. >I do not want to focus on IPv4 deployment issues that may arise with >existing implementations. I don't believe I have mentioned IPv4 other than pointing to operational experience. What we are talking about maps equally to IPv4 or IPv6. >It seems that most people are supportive of limiting the filtering to the >edges of the network. This would help mobility immensely in that home >addresses could be used as the source address and remove a bunch of issues >with tunneling. Have you gotten any operators to say that? You haven't made much of a case until you have operational support. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 21:47: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 VAA26638 for ; Wed, 11 Oct 2000 21:47:56 -0400 (EDT) Received: from standards (47.234.32.16:3379) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA206E@standards.nortelnetworks.com>; Wed, 11 Oct 2000 21:31:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2303 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 21:31:10 -0400 Received: from explore.kwangwoon.ac.kr (128.134.70.30:53616) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2064@standards.nortelnetworks.com>; Wed, 11 Oct 2000 21:21:09 -0400 Received: from eos (eos.kwangwoon.ac.kr [128.134.56.162]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id KAA10039 for ; Thu, 12 Oct 2000 10:32:59 +0900 (KST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C03438.6141F7A0" 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 Message-ID: <001101c033ec$f1e096a0$a2388680@kwangwoon.ac.kr> Date: Thu, 12 Oct 2000 10:37:12 +0900 Reply-To: SungJin Lee Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: SungJin Lee Subject: [MOBILE-IP] MIPv6 node location detection To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C03438.6141F7A0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SSBnb3QgY29uZmlzdWVkIHdoaWxlIGkgd2FzIHJlYWRpbmcgTUlQdjYgc3RhbmRhcmRzIGFuZA0K aGF2ZSBhIGNvdXBsZSBvZiBxdWVzdGlvbiB3aXRoIGNhc2VzIGxpa2UgZm9sbG93aW5nLiBUaGUg DQpJdCBpcyBhc3N1bWVkIHRoYXQgdGhlIE1JUHY2IG5vZGUgdXNlIHN0YXRlbGVzcyBhdXRvY29u ZmlndXJhdGlvbi4gDQpMZXQgbWUga25vdyBpZiAgaSBsb3N0IHNvbWUgaW4gTUlQdjYgYW5kIElQ djYgUkZDLg0KDQpRLjEgICBBIE1JUHY2IG5vZGUgbW92ZWQgdG8gZm9yZWlnbiBsaW5rLiBUaGUg TUlQdjYgbm9kZSByZXN0YXJ0cyANCiAgICAgICAgdGhlIHN5c3RlbSB0aGVyZSBhbmQgcmVjZWl2 ZXMgIHJvdXRlciBhZHZlcnRpc2VtZW50cyB3aXRoIA0KICAgICAgICBmb3JlaWduIG5ldHdvcmsg cHJlZml4Lg0KICAgICAgICANCiAgICAgICAgSG93IGRvIHRoZSBNSVB2NiBub2RlIGRldGVjdCBp ZiBpdCBpcyBsb2NhdGVkIGluIGZvcmVpZ24gbGluayA/DQogICAgICAgIGlzbid0IGl0IGNvdWxk IGJlIG5vcm1hbCBhdXRvY29uZmlndXJhdGlvbiBhcyBpbiB0aGUgaG9tZSBsbGluayA/DQoNClEu MiAgIEEgTUlQdjYgbm9kZSBsb2NhdGVkIGluIGl0J3MgaG9tZSBsaW5rLiBUaGUgbm9kZSBnb3Qg YW4gSVAgYWRkcmVzcw0KICAgICAgICB3aXRoIHN0YXRlbGVzcyBhdXRvY29uZmlndXJhdGlvbi4g QXQgYSB0aW1lIHRoZSByb3V0ZXIgY2hhbmdlZCB0aGUgaG9tZSBsaW5rDQogICAgICAgIHByZWZp eCBhbmQgbXVsdGljYXN0IHRoZSByb3V0ZXIgYWR2ZXJ0aXNlbWVudCB3aXRoIG5ldyBwcmVmaXgu IA0KICAgICAgICBBZnRlciB0aGUgaG9tZSBsaW5rIHByZWZpeCBpZmV0aW1lIGV4cGlyZWQgb3Ig YmVmb3JlIHRoZSBsaWZlIHRpbWUgDQogICAgICAgZXhwaXJlZCwgaXQgcmVjZWl2ZWQgcm91dGVy IGFkdmVydGlzZW1lbnQgd2l0aCBuZXcgcHJlZml4LiANCg0KICAgICAgIFdoeSBkb2Vzbid0IHRo ZSBJUHY2IG5vZGUgdGhpbmsgaXQncyBsb2NhdGVkIGluIGZvcmVpZ24gbGluayB3aGVuIGl0DQog ICAgICAgIHJlY2VpdmVkID8gaXNuJ3QgaXQgcG9zc2libGUgdGhlIElQdjYgbm9kZSB0byB0aGlu ayBpdCdzIG1vdmVkIHRvIGEgZm9yZWlnbg0KICAgICAgICBsaW5rIGFuZCBzdGFydCBNSVB2NiBw cm9jZXNzID8NCg0KDQo= ------=_NextPart_000_000E_01C03438.6141F7A0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQxMzQuNjAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+SSBnb3QgY29u ZmlzdWVkIHdoaWxlIGkgd2FzIHJlYWRpbmcmbmJzcDtNSVB2NiBzdGFuZGFyZHMgDQphbmQ8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5oYXZlIGEgY291cGxlIG9mIHF1ZXN0aW9uIHdp dGggY2FzZXMgbGlrZSBmb2xsb3dpbmcuJm5ic3A7VGhlIA0KPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTI+SXQgaXMgYXNzdW1lZCB0aGF0IHRoZSBNSVB2NiBub2RlJm5ic3A7dXNlIHN0 YXRlbGVzcyANCmF1dG9jb25maWd1cmF0aW9uLjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPkxldCBtZSBrbm93IGlmJm5ic3A7IGkgbG9zdCZuYnNwO3NvbWUgPC9GT05UPjxG T05UIA0Kc2l6ZT0yPmluJm5ic3A7TUlQdjYgYW5kIElQdjYgUkZDLjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlEu MSZuYnNwOyZuYnNwOyBBJm5ic3A7TUlQdjYgbm9kZSBtb3ZlZCB0byBmb3JlaWduIA0KbGluay4m bmJzcDs8L0ZPTlQ+PEZPTlQgc2l6ZT0yPlRoZSZuYnNwO01JUHY2IG5vZGUgcmVzdGFydHMgPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHRoZSBzeXN0ZW0gdGhlcmUgDQphbmQgcmVjZWl2ZXM8L0ZPTlQ+PEZP TlQgc2l6ZT0yPiZuYnNwOyByb3V0ZXIgDQphZHZlcnRpc2VtZW50cyZuYnNwO3dpdGgmbmJzcDs8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgZm9yZWlnbiBuZXR3b3JrIA0KcHJlZml4LjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSG93IGRvIHRoZSBNSVB2NiANCm5vZGUgZGV0ZWN0IGlm IGl0IGlzIGxvY2F0ZWQgaW4gZm9yZWlnbiZuYnNwO2xpbmsgPzwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO2lzbid0IGl0IGNvdWxkIA0KYmUgbm9ybWFsIGF1dG9jb25maWd1cmF0aW9uIGFzIGluIHRo ZSBob21lIGxsaW5rID88L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBzaXplPTI+US4yJm5ic3A7Jm5ic3A7Jm5ic3A7QSBNSVB2NiBub2RlIGxvY2F0ZWQgaW4mbmJz cDtpdCdzIGhvbWUgDQpsaW5rLiZuYnNwO1RoZSBub2RlIGdvdCBhbiZuYnNwO0lQIGFkZHJlc3M8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgd2l0aCBzdGF0ZWxlc3MgDQphdXRvY29uZmlndXJhdGlvbi4gQXQg YSB0aW1lIHRoZSByb3V0ZXIgY2hhbmdlZCB0aGUgaG9tZSBsaW5rPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNw O3ByZWZpeCBhbmQgDQptdWx0aWNhc3QgdGhlIHJvdXRlciBhZHZlcnRpc2VtZW50IHdpdGggbmV3 IHByZWZpeC4gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFmdGVyJm5ic3A7dGhlIGhvbWUgDQpsaW5rIHBy ZWZpeCBpZmV0aW1lJm5ic3A7ZXhwaXJlZCZuYnNwOzwvRk9OVD48Rk9OVCBzaXplPTI+b3IgYmVm b3JlJm5ic3A7dGhlIA0KbGlmZSB0aW1lIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCmV4cGlyZWQsPC9GT05UPiZu YnNwOzxGT05UIHNpemU9Mj5pdCByZWNlaXZlZCByb3V0ZXIgYWR2ZXJ0aXNlbWVudCB3aXRoIA0K bmV3Jm5ic3A7PC9GT05UPjxGT05UIHNpemU9Mj5wcmVmaXguIDwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXaHkgZG9lc24ndCB0aGUgSVB2NiBub2Rl IA0KdGhpbmsgaXQncyBsb2NhdGVkIGluIGZvcmVpZ24gbGluayB3aGVuIGl0PC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7cmVjZWl2ZWQgPyANCmlzbid0IGl0IHBvc3NpYmxlIHRoZSBJUHY2IG5vZGUg dG8gdGhpbmsgaXQncyBtb3ZlZCB0byBhIGZvcmVpZ248L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGluayBh bmQgc3RhcnQgDQpNSVB2NiBwcm9jZXNzID88L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_000E_01C03438.6141F7A0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 22:26: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 WAA27162 for ; Wed, 11 Oct 2000 22:26:33 -0400 (EDT) Received: from standards (47.234.32.16:3379) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA20D6@standards.nortelnetworks.com>; Wed, 11 Oct 2000 22:09:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2452 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 22:09:56 -0400 Received: from mailhost.iprg.nokia.com (205.226.5.12:54783) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA20D4@standards.nortelnetworks.com>; Wed, 11 Oct 2000 22:09:55 -0400 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 TAA28935; Wed, 11 Oct 2000 19:24:45 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9C2Ogm27518; Wed, 11 Oct 2000 19:24:42 -0700 X-Virus-Scanned: Wed, 11 Oct 2000 19:24:42 -0700 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) smtpd4vmzJq; Wed, 11 Oct 2000 19:24:37 PDT X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39E5206D.2543EC06@iprg.nokia.com> Date: Wed, 11 Oct 2000 19:22:37 -0700 Reply-To: Charlie Perkins Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Charlie Perkins Organization: Nokia Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA X-To: Fredrik Johansson To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, The statement has been made that the Registration Request does not contain a challenge. This isn't correct. The "Identification" field of the Registration Request message serves exactly the function of a challenge, from the standpoint of the home agent. I reckon it would be fairly easy to establish a security association between the mobile node and the home agent that would enable RADIUS to be used by the home agent, but there are details that would have to be worked out. Regards, Charlie P. Fredrik Johansson wrote: > Hi, > > the mobile node generates the challenge and send the request to the home > agent. The home agent will then include the same challenge in the > registration reply, is it up to the implementation of the co-located foreign > agent to remove the challenge before giving it to the mobile client so it is > not misstaken for a new challenge that can be sent in the registration reply > for use in the next registration? > > /Fredrik > > > -----Original Message----- > > From: IP Routing for Wireless/Mobile Hosts (mobile-ip) > > [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Woo-June Kim > > Sent: den 6 oktober 2000 17:28 > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA > > > > > > Fredrik, > > > > The mobile node itself just generates a random number to use as > > the challenge. The response can only be correctly calculated by > > the mobile if it knows the correct key and algorithm. The AAA is > > simply using this fact to check the mobile's identity in a > > round-about manner. The challenge value itself is not something > > that must be generated in some special manner. > > > > cheers > > > > >BlankHi > > > > > >I have a question concerning how Challenge / Response is supposed to work > > >when a mobile node registers using a co-located foreign agent. > > > > > >Since the mobile node does not receive an advertisement with a challenge > > >from a FA it cannot calculate a response to be used in a MN-AAA > > >Authentication extension, i.e., the Home Agent cannot use a > > Radius server to > > >authenticate the MN. > > > > > >Have there been any thoughts in this area, or perhaps a solution in an > > >earlier thread that I've missed? Thankful for any pointers. > > > > > >Regards > > >/Fredrik > > >----------------------------------------- > > >Fredrik Johansson > > > > > >W: +46 (0)8 725 5916 > > >M: +46 (0)70 786 5035 > > >mailto:Fredrik.Johansson@ipunplugged.com > > >http://www.ipunplugged.com > > > > > > > > > > > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 00:15: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 AAA29542 for ; Thu, 12 Oct 2000 00:15:10 -0400 (EDT) Received: from standards (47.234.32.16:4065) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA214F@standards.nortelnetworks.com>; Wed, 11 Oct 2000 23:58:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2609 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 23:58:18 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA214D@standards.nortelnetworks.com>; Wed, 11 Oct 2000 23:58:18 -0400 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 VAA04085; Wed, 11 Oct 2000 21:13:08 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9C4D5I03147; Wed, 11 Oct 2000 21:13:05 -0700 X-Virus-Scanned: Wed, 11 Oct 2000 21:13:05 -0700 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) smtpdIB4uTd; Wed, 11 Oct 2000 21:13:00 PDT X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4.3.2.7.2.20001010233421.00ce6cc0@omega.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39E539CE.7285BF59@iprg.nokia.com> Date: Wed, 11 Oct 2000 21:10:54 -0700 Reply-To: Charlie Perkins Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Charlie Perkins Organization: Nokia Subject: Re: [MOBILE-IP] WG Last Call -(draft-ietf-mobileip-reg-tunnel-03.txt) X-To: Gopal Dommety To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Gopal, > 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 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. It's not a simple issue. > 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. > 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 protocol needs to handle all cases as best it can do. > 2. What is the implementation of the current version of the Draft (not the previous versions)? We have an implementation. I have heard of others, which of course I don't want to disclose without permission. Maybe we should try for an interoperability test. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 01:03: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 BAA00037 for ; Thu, 12 Oct 2000 01:03:31 -0400 (EDT) Received: from standards (47.234.32.16:2406) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA21E8@standards.nortelnetworks.com>; Thu, 12 Oct 2000 0:46:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2811 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 00:46:40 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA21E6@standards.nortelnetworks.com>; Thu, 12 Oct 2000 0:36:38 -0400 Received: from mail.proctors.com.au (mrkal-gw.kal.emerge.net.au [203.57.132.65]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id XAA05031 for ; Wed, 11 Oct 2000 23:51:12 -0500 (CDT) Received: from monorailpc by mail.proctors.com.au (Lotus SMTP MTA v1.05 (274.9 11-27-1996)) with SMTP id 48256967.0039953D; Sun, 27 Sep 1970 18:28:13 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Message-ID: <200010120451.XAA05031@hosaka.smallworks.com> Date: Wed, 11 Oct 2000 23:51:12 -0500 Reply-To: donald453@BBC.CO.UK Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: donald453@BBC.CO.UK Subject: [MOBILE-IP] Porche Boxter or Luxury Cruise Earn $$$ In Days This Works!!! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Dear Friend, This really works! Have the faith, don't miss this opportunity, get involved also, and it will work for you as it does for us!!!!! Thank you for your time and interest. This email contains the ENTIRE PLAN of how YOU can make $50,000 or more in the next 90 days simply sending email! Seem impossible? Just read on and see how easy this is.... Due to the popularity of this letter on the Internet, a major nightly news program recently devoted an entire show to the investigation of the program described below to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved that there are absolutely no laws prohibiting participation in the program. This has helped to show people that this is a simple, harmless and fun way to make some extra money at home. The results have been truly remarkable. So many people are participating that those involved are doing much better than ever before. Since everyone makes more as more people try it out, its been very exciting. You will understand once you try it yourself! ********* THE ENTIRE PLAN IS HERE BELOW ********* *** Print This Now For Future Reference *** $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $50,000 in less than 90 days, please read this program...THEN READ IT AGAIN!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY!! It does NOT require you to come into contact with people or make or take any telephone calls. Just follow the instructions, and you will make money. This simplified e-mail marketing program works perfectly 100% EVERY TIME! E-mail is the sales tool of the future. Take advantage of this virtually free method of advertising NOW!!! The longer you wait, the more people will be doing business using email. Get your piece of this action!!! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hello - My name is Johnathon Rourke, I'm from Rhode Island. The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave some thought and study to it. Two years ago, the corporation I worked for for the past twelve years down-sized and my position was eliminated. After unproductive job interviews, I decided to open my own business. Over the past year, I incurred many unforeseen financial problems. I owed my family, friends and creditors over $35,000. The economy was taking a toll on my business and I just couldn´t seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life. I am writing toshare the experience in hopes that this could change your life FOREVER. FINANCIALLY$$$!!! In mid December, I received this program in my e-mail. Six months prior to receiving this program I had been sending away for information on various business opportunities. All of the programs I received, in my opinion, were not cost effective. They were either too difficult for me to comprehend or the initial investment was too much for me to risk to see if they would work. But as I was saying, in December of 1997 I received this program. I didn´t send for it, or ask for it, they just got my name off a mailing list. THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly. I couldn´t believe my eyes! Here was a MONEY MAKING MACHINE I could start immediately without any debt. Like most of you I was still a little skeptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 24-hrs) and they confirmed that it is indeed legal! After determining the program was LEGAL I decided "WHY NOT!?!??" Initially I sent out 10,000 e-mails. It cost me about $15 for my time on-line. The great thing about e-mail is that I don´t need any money for printing to send out the program, and because I also send the product (reports) by e-mail, my only expense is my time. In less than one week, I was starting to receive orders for REPORT #1. By January 13, I had received 26 orders for REPORT #1. Your goal is to "RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON´T, SEND OUT MORE PROGRAMS UNTIL YOU DO. My first step in making $50,000 in 90 days was done. By January 30, I had received 196 orders for REPORT #2. Your goal is to "RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL." Well, I had 196 orders for REPORT #2, 96 more than I needed. So I sat back and relaxed. By March 1, of my e-mailing of 10,000, I received $58,000 with more coming in every day. I paid off ALL my debts and bought a much needed new car! Please take your time to read this plan, IT WILL CHANGE YOUR LIFE FOREVER$!!! Remember, it won´t work if you don´t try it. This program does work, but you must follow it EXACTLY! Especially the rules of not trying to place your name in a different place. It won´t work and you´ll lose out on a lot of money! In order for this program to work, you must meet your goal of 20+ orders for REPORT #1, and 100+ orders for REPORT #2 and you will make $50,000 or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!! If you choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to you. If you choose to participate, follow the program and you will be on your way to financial security. If you are a fellow business owner and are in financial trouble like I was, or you want to start your own business, consider this a sign. I DID! $$ Sincerely, Johnathon Rourke ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you have read the enclosed program and reports, you should have concluded that such a program, and one that is legal, could not have been created by an amateur. Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my business began falling off. I was doing the same things that were previously successful for me, but it wasn´t working. Finally, I figured it out. It wasn´t me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945. I don´t have to tell you what happened to the unemployment rate...because many of you know from first hand experience. There were more failures and bankruptcies than ever before. The middle class was vanishing. Those who knew what they were doing invested wisely and moved up. Those who did not, including those who never had anything to save or invest, were moving down into the ranks of the poor. As the saying goes, "THE RICH GET RICHER AND THE POOR GET POORER." The traditional methods of making money will never allow you to "move up" or "get rich." Inflation will see to that. You have just received information that can give you financial freedom for the rest of your life, with "NO RISK" and "JUST A LITTLE BIT OF EFFORT." You can make more money in the next few months than you have ever imagined. I should also point out that I will not see a penny of this money, nor anyone else who has provided a testimonial for this program. I have retired from the program after sending thousands and thousands of programs. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report to everyone you can think of. One of the people you send this to may send out 50,000...and your name will be on every one of them! Remember though, the more you send out, the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU!! NOW DO IT!! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Before you delete this program from your in box, as I almost did, take a little time to read it and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when YOU participate. Figure out the worst possible response and no matter how you calculate it, you will still make a lot of money! You will definitely get back what you invested. Any doubts you have will vanish when your first orders come in. $$$ IT WORKS!!! $$$ Jody Jacobs Richmond, VA ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ HERE´S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLAR$$$$!!!! This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use up to $50,000 or more in the next 90 days. Before you say "BULL... ", please read this program carefully. This is not a chain letter, but a perfectly legal money making business. As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Every state in the USA allows you to recruit new multi-level business partners, and we sell and deliver a product for EVERY dollar received. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store or office. This is the EASIEST marketing plan anywhere! It is simply order-filling by email! ******************************************************************* The product is informational and instructional material, keys to the secrets for everyone on how to open the doors to the magic world of E- COMMERCE, the information highway, the wave of the future! PLAN SUMMARY: (1) You order the 4 reports listed below ($5 US each.) They come to you by email. (2) Save a copy of this entire letter and put your name after Report #1 and move the other names down. (3) Via the internet, access Yahoo.com or any of the other major search engines to locate hundreds of bulk email service companies (search for "bulk email") and have them send 25,000 - 50,000 emails for you about $49+). (4) Orders will come to you by postal mail - simply email them the Report they ordered. Let me ask you - isn´t this about as easy as it gets? ************************************************************ By the way there are over 50 MILLION email addresses with millions more joining the internet each year so don´t worry about "running out" or "saturation". People are used to seeing and hearing the same advertisements every day on radio/TV. How many times have you received the same pizza flyers on your door? Then one day you are hungry for pizza and you order one. Same thing with this letter. I received this letter many times - then one day I decided it was time to try it. ************************************************************ YOU CAN START TODAY - JUST DO THESE EASY STEPS: STEP #1. ORDER THE FOUR REPORTS Order the four reports shown on the list below (you can´t sell them if you don´t order them). -- For each report, send $5.00 (US) CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! Within a few days you will receive, by e-mail, each of the four reports. Save them on your computer so you can send them to the 1,000´s of people who will order them from you. STEP #2. ADD YOUR MAILING ADDRESS TO THIS LETTER a. Look below for the listing of the four reports. b. After you´ve ordered the four reports, delete the name and address under REPORT #4. This person has made it through the cycle. c. Move the name and address under REPORT #3 down to REPORT #4. d. Move the name and address under REPORT #2 down to REPORT #3. e. Move the name and address under REPORT #1 down to REPORT #2. f. Insert your name and address in the REPORT #1 position. Please make sure you COPY ALL INFORMATION, every name and address, ACCURATELY! STEP #3. SAVE THIS LETTER Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to these instructions. Now you are ready to use this entire email to send by email to prospects. Report #1 will tell you how to download bulk email software and email addresses so you can send it out to thousands of people while you sleep! Remember that 50,000+ new people are joining the internet every month. Your cost to participate in this is practically nothing; surely you can afford $20 (US) and initial bulk mailing cost. You obviously already have a computer and an Internet connection and e-mail is FREE! There are two primary methods of building your downline: METHOD #1: SENDING BULK E-MAIL Let´s say that you decide to start small, just to see how it goes, and we´ll assume you and all those involved email out only 2,000 programs each. Let´s also assume that the mailing receives a 0.5% response. The response could be much better. Also, many people will email out hundreds of thousands of programs instead of 2,000. (Why stop at 2000?). But continuing with this example, you send out only 2,000 programs. With a 0.5% response, that is only 10 orders for REPORT #1. Those 10 people respond by sending out 2,000 programs each for a total of 20,000. Out of those 0.5% 100 people respond and order REPORT #2. Those 100 mail out 2,000 programs each for a total of 200,000. The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000 send out 2,000 programs each for a 2,000,000 total. The 0.5% response to that is 10,000 orders for REPORT #4. That´s 10,000 $5 bills for you. CASH!!! Your total income in this example is $50 + $500 + $5,000 + $50,000 for a total of $55,550!!! REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will do just that, and more! METHOD #2: PLACING FREE ADS ON THE INTERNET Advertising on the internet is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let´s say you decide to start small just to see how well it works. Assume your goal is to get ONLY 10 people to participate on your first level. (Placing a lot of FREE ads on the Internet will EASILY get a larger response.) Also assume that everyone else in YOUR ORGANIZATION gets ONLY 10 downline members. Look how this small number accumulates to achieve the STAGGERING results below: 1st level--your first 10 send you $5..................................$50 2nd level--10 members from those 10 ($5 x 100).............$500 3rd level--10 members from those 100 ($5 x 1000)........$5,000 4th level--10 members from those 1000 ($5 x 10,000)..$50,000 $$$$$$ THIS TOTALS ----------$55,550 $$$$$$ AMAZING ISN´T IT? Remember friends, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 100´s of participants and many will continue to work this program, sending out programs WITH YOUR NAME ON THEM for years! THINK ABOUT IT! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ People are going to get emails about this plan from you or somebody else and many will work this plan. The question is, don´t you want your name to be on the emails they will send out? * * * DON´T MISS OUT!!! * * * JUST TRY IT ONCE!!! * * * * * SEE WHAT HAPPENS!!! *** YOU´LL BE AMAZED!!!* * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out with YOUR name and address on it will be prompt because they can´t advertise until they receive the report! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GET STARTED TODAY: PLACE YOUR ORDER FOR THE FOUR REPORTS NOW. Notes: ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT ACCEPTED. Make sure the cash is concealed by wrapping it in two sheets of paper. On one of those sheets of paper write: (a) the number & name of the report you are ordering (b) your e-mail address, and (c) your name & postal address. REPORT #1 "The Insider´s Guide to Advertising for Free on the Internet" ORDER REPORT #1 FROM: Andrew Skidmore 9379 Alexander Rd Alexander, NY 14005 USA REPORT #2 "The Insider´s Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #2 FROM: Lars Pedersen Skejbygaardsvej 7, 1, 10 8240 Risskov Denmark REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: John Cole Werner PO Box 3281 Lihue, HI 96766 REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: Zac Majors 2242 E Woodchuck Way Sandy, UT 84093 ******* TIPS FOR SUCCESS ******* TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/report. It is required for this to be a legal business and they need the reports to send out their letters (with your name on them!) -- ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. -- Be patient and persistent with this program - If you follow the instructions exactly - results WILL FOLLOW. $$$$ ******* YOUR SUCCESS GUIDELINES ******* Follow these guidelines to guarantee your success: If you don´t receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mails until you do. Then, a couple of weeks later you should receive at least 100 orders for REPORT #2. If you don´t, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. To generate more income, simply send another batch of e-mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program, please answer one question. ARE YOU HAPPY WITH YOUR PRESENT INCOME OR JOB? If the answer is no, then please look at the following facts about this super simple MLM program: 1. NO face to face selling, NO meetings, NO inventory! NO Telephone calls, NO big cost to start! NOthing to learn, NO skills needed! (Surely you know how to send email?) 2. No equipment to buy - you already have a computer and internet connection - so you have everything you need to fill orders! 3. You are selling a product which does NOT COST ANYTHING TO PRODUCE OR SHIP! (Emailing copies of the reports is FREE!) 4. All of your customers pay you in CA$H! This program will change your LIFE FOREVER!! Look at the potential for you to be able to quit your job and live a life of luxury you could only dream about! Imagine getting out of debt and buying the car and home of your dreams and being able to work a super-high paying leisurely easy business from home! $$$ FINALLY MAKE SOME DREAMS COME TRUE! $$$ ACT NOW! Take your first step toward achieving financial independence. Order the reports and follow the program outlined above-- SUCCESS will be your reward. Thank you for your time and consideration. PLEASE NOTE: If you need help with starting a business, registering a business name, learning how income tax is handled, etc., contact your local office of the Small Business Administration (a Federal Agency) at 1-800-827-5722 for free help and answers to questions. Also, the Internal Revenue Service offers free help via telephone and free seminars about business tax requirements. Your earnings are highly dependent on your activities and advertising. The information contained on this site and in the report constitutes no guarantees stated nor implied. In the event that it is determined that this site or report constitutes a guarantee of any kind, that guarantee is now void. The earnings amounts listed on this site and in the report are estimates only. If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection in Washington, DC. ================================================ Under Bill s.1618 TITLE III passed by the 105th US Congress this letter cannot be considered spam as long as the sender includes contact information and a method of removal. This is a one time e-mail transmission. No request for removal is necessary. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 01:34: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 BAA04217 for ; Thu, 12 Oct 2000 01:34:43 -0400 (EDT) Received: from standards (47.234.32.16:2406) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA224A@standards.nortelnetworks.com>; Thu, 12 Oct 2000 1:17:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2941 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 01:17:43 -0400 Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2248@standards.nortelnetworks.com>; Thu, 12 Oct 2000 1:17:43 -0400 Received: from gopal.cisco.com (gdommety-dsl3.cisco.com [10.19.17.140]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id WAA16130; Wed, 11 Oct 2000 22:32:31 -0700 (PDT) X-Sender: gdommety@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 References: <4.3.2.7.2.20001010233421.00ce6cc0@omega.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.3.2.7.2.20001011220851.00cd3f00@omega.cisco.com> Date: Wed, 11 Oct 2000 22:35:47 -0700 Reply-To: Gopal Dommety Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gopal Dommety Subject: Re: [MOBILE-IP] WG Last Call -(draft-ietf-mobileip-reg-tunnel-03.txt) X-To: Charlie Perkins To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <39E539CE.7285BF59@iprg.nokia.com> 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 Thu Oct 12 02:42: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 CAA13437 for ; Thu, 12 Oct 2000 02:42:47 -0400 (EDT) Received: from standards (47.234.32.16:2406) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA232E@standards.nortelnetworks.com>; Thu, 12 Oct 2000 2:25:47 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3229 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 02:25:47 -0400 Received: from mail.hansvision.com (202.106.155.176:1950) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2323@standards.nortelnetworks.com>; Thu, 12 Oct 2000 2:15:45 -0400 Received: from FlashMail ([202.106.155.165]) by mail.hansvision.com (8.9.3/8.8.7) with SMTP id OAA08120 for ; Thu, 12 Oct 2000 14:17:14 -0400 X-Mailer: The Bat! (v1.46) Personal X-Priority: 3 (Normal) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <54465749.20001012142829@hansvision.com> Date: Thu, 12 Oct 2000 14:28:29 +0800 Reply-To: leeds Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: leeds Subject: [MOBILE-IP] unsubscribe To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id CAA13437 unsubscribe . From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 03:16: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 DAA13585 for ; Thu, 12 Oct 2000 03:16:26 -0400 (EDT) Received: from standards (47.234.32.16:2406) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA23C6@standards.nortelnetworks.com>; Thu, 12 Oct 2000 2:59:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3437 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 02:59:21 -0400 Received: from stargate.ipunplugged.com (195.42.212.161:24247) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA23C4@standards.nortelnetworks.com>; Thu, 12 Oct 2000 2:59:20 -0400 Received: from FREDRIKJPC ([192.168.4.218]) by stargate.ipunplugged.com (8.9.3/8.9.3) with SMTP id JAA03244; Thu, 12 Oct 2000 09:11:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Message-ID: Date: Thu, 12 Oct 2000 09:15:12 +0300 Reply-To: Fredrik Johansson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fredrik Johansson Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit Thanks Pat, That is exactly my opinion. My first intuition was that it is not secure for the mobile node to create its own challenge. It will open up for DoS attacks against the radius server since the home agent will not reject any registration request but will try to authenticate them all towards the radius server. We've been thinking about the solution where the home agent rejects the first request. If the mobile node try to register to the home agent without the challenge extension. The home agent will return a registration reply with the error code "missing challenge", and includes a challenge in the reply. The mobile node will try to register again now including the received challenge. The home agent MUST check that the received challenge is the same as the one sent in the previous reply to this mobile node. When the home agent has authenticated the mobile node, it sends a registration reply with a new challenge that the mobile node MUST use in the next periodic registration. If a registration reply gets lost on its way to the mobile node, the mobile node will try again with the same challenge and now the home agent will reject the request with the error code "stale challenge". And return a new challenge in the reply, thus causing the mobile node to try again. This requires some changes in how the home agent handles registration request. First if the home agent is configured to authenticate its users towards a radius server it has to return a new challenge in the reply. It MUST also keep a copy of the last challenge sent to the mobile node so it can compare it against the one recieved in the next registration reply. The implementation of the co-located foreign agent has to inteprete the recieved challenge as a new one instead of an old one as menitioned earlier in this thread. Open issues: * how will the home agent know if it is a co-located foreign agent or an regular foreign agent it is dealing with, i.e. how will it know when it should return the old challenge to the foreign agent or a new challenge to the co-located foreign agent? Pros & Cons: * Challenge response is available for a mobile node regisering as a co-located foreign agent which will enable radius authentication. * The first registration will need 2 RTT. I'm not that familiar with the procedures when a draft becomes an RFC, but if there is time, I believe something should be mentioned in the draft about how it will work with a co-located foreign agent. /Fredrik > -----Original Message----- > From: pcalhoun@eng.sun.com [mailto:Pat.Calhoun@eng.sun.com] > Sent: den 11 oktober 2000 17:02 > To: Fredrik Johansson > Cc: pcalhoun@eng.sun.com; MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: RE: [MOBILE-IP] Challenge / Response with co-located FA > > > Ahh... sorry. I thought your question was in regards to the challenge > extension, and not the MN-AAA authentication extension. > > In any case, for the latter, it does require that the former be > present, and > the mobile can generate its own challenge (hmmmm.... quite insecure, isn't > it). I am also tempted to say that the Home Agent should return > an new error > code with a challenge value, and force the Mobile Node to re-register. > > Unfortunately, the soon to be RFC doesn't discuss co-location. > > PatC > > Hi Pat, > > > > It was not to provide replay protection but to enable the home agent to > > authenticate the user towards a Radius server using CHAP. In the radius > > request a challenge and a response is needed. Using the MN-HA > > Authentication extension does not provide a challenge. > > > > Or is there another way of doing this? > > > > /Fredrik > > > > > -----Original Message----- > > > From: pcalhoun@eng.sun.com [mailto:Pat.Calhoun@Eng.Sun.COM] > > > Sent: den 11 oktober 2000 16:40 > > > To: Fredrik Johansson > > > Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA > > > > > > > > > Well, perhaps I am missing something here, but I really don't see > > > the need for > > > challenge/response support in a co-located MN. The challenge is > > > useful to FAs > > > to provide replay protection. Since MNs already have a replay > protection > > > scheme with the Home Agent, the challenge doesn't provide > > > anything additional. > > > > > > PatC > > > > Hi, > > > > > > > > the mobile node generates the challenge and send the > request to the home > > > > agent. The home agent will then include the same challenge in the > > > > registration reply, is it up to the implementation of the > > > co-located foreign > > > > agent to remove the challenge before giving it to the mobile > > > client so it is > > > > not misstaken for a new challenge that can be sent in the > > > registration reply > > > > for use in the next registration? > > > > > > > > /Fredrik > > > > > > > > > -----Original Message----- > > > > > From: IP Routing for Wireless/Mobile Hosts (mobile-ip) > > > > > [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of > > > Woo-June Kim > > > > > Sent: den 6 oktober 2000 17:28 > > > > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA > > > > > > > > > > > > > > > Fredrik, > > > > > > > > > > The mobile node itself just generates a random number to use as > > > > > the challenge. The response can only be correctly calculated by > > > > > the mobile if it knows the correct key and algorithm. The AAA is > > > > > simply using this fact to check the mobile's identity in a > > > > > round-about manner. The challenge value itself is not something > > > > > that must be generated in some special manner. > > > > > > > > > > cheers > > > > > > > > > > >BlankHi > > > > > > > > > > > >I have a question concerning how Challenge / Response is > > > supposed to work > > > > > >when a mobile node registers using a co-located foreign agent. > > > > > > > > > > > >Since the mobile node does not receive an advertisement with > > > a challenge > > > > > >from a FA it cannot calculate a response to be used in a MN-AAA > > > > > >Authentication extension, i.e., the Home Agent cannot use a > > > > > Radius server to > > > > > >authenticate the MN. > > > > > > > > > > > >Have there been any thoughts in this area, or perhaps a > > > solution in an > > > > > >earlier thread that I've missed? Thankful for any pointers. > > > > > > > > > > > >Regards > > > > > >/Fredrik > > > > > >----------------------------------------- > > > > > >Fredrik Johansson > > > > > > > > > > > >W: +46 (0)8 725 5916 > > > > > >M: +46 (0)70 786 5035 > > > > > >mailto:Fredrik.Johansson@ipunplugged.com > > > > > >http://www.ipunplugged.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 03:55: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 DAA13811 for ; Thu, 12 Oct 2000 03:55:36 -0400 (EDT) Received: from standards (47.234.32.16:2406) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2461@standards.nortelnetworks.com>; Thu, 12 Oct 2000 3:38:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3638 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 03:38:48 -0400 Received: from stargate.ipunplugged.com (195.42.212.161:24277) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA245F@standards.nortelnetworks.com>; Thu, 12 Oct 2000 3:38:47 -0400 Received: from FREDRIKJPC ([192.168.4.218]) by stargate.ipunplugged.com (8.9.3/8.9.3) with SMTP id JAA03490; Thu, 12 Oct 2000 09:51:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Message-ID: Date: Thu, 12 Oct 2000 09:55:03 +0300 Reply-To: Fredrik Johansson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fredrik Johansson Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA X-To: Charlie Perkins To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <39E5206D.2543EC06@iprg.nokia.com> Content-Transfer-Encoding: 7bit Hi Charlie That is true that the "Identification" field contains a challenge, but that is from the mobile node towards the home agent. What we're looking for is the oposite direction, from the home agent to the mobile node. In order to authenticate the user towards a Radius server using CHAP, a challenge and a reponse is needed. Thus we need something like the MN-AAA Authentication extension. By doing the authentication with a Radius server, the mobile node will only need to keep one shared secret between the mobile node and ANY home agent on the home network, since when authenticated with the Radius server, the home agent will retrieve the subscriber data for that mobile node. This will make home agent discovery easier since a new home agent can be deployed on the home network without having to configure the mobile node with yet another shared key. Regards /Fredrik > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: den 12 oktober 2000 05:23 > To: Fredrik Johansson > Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA > > > > Hello, > > The statement has been made that the Registration Request does > not contain a challenge. This isn't correct. The "Identification" field > of the Registration Request message serves exactly the function > of a challenge, from the standpoint of the home agent. I reckon it > would be fairly easy to establish a security association between the > mobile node and the home agent that would enable RADIUS to > be used by the home agent, but there are details that would have > to be worked out. > > Regards, > Charlie P. > > > Fredrik Johansson wrote: > > > Hi, > > > > the mobile node generates the challenge and send the request to the home > > agent. The home agent will then include the same challenge in the > > registration reply, is it up to the implementation of the > co-located foreign > > agent to remove the challenge before giving it to the mobile > client so it is > > not misstaken for a new challenge that can be sent in the > registration reply > > for use in the next registration? > > > > /Fredrik > > > > > -----Original Message----- > > > From: IP Routing for Wireless/Mobile Hosts (mobile-ip) > > > [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of > Woo-June Kim > > > Sent: den 6 oktober 2000 17:28 > > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA > > > > > > > > > Fredrik, > > > > > > The mobile node itself just generates a random number to use as > > > the challenge. The response can only be correctly calculated by > > > the mobile if it knows the correct key and algorithm. The AAA is > > > simply using this fact to check the mobile's identity in a > > > round-about manner. The challenge value itself is not something > > > that must be generated in some special manner. > > > > > > cheers > > > > > > >BlankHi > > > > > > > >I have a question concerning how Challenge / Response is > supposed to work > > > >when a mobile node registers using a co-located foreign agent. > > > > > > > >Since the mobile node does not receive an advertisement with > a challenge > > > >from a FA it cannot calculate a response to be used in a MN-AAA > > > >Authentication extension, i.e., the Home Agent cannot use a > > > Radius server to > > > >authenticate the MN. > > > > > > > >Have there been any thoughts in this area, or perhaps a > solution in an > > > >earlier thread that I've missed? Thankful for any pointers. > > > > > > > >Regards > > > >/Fredrik > > > >----------------------------------------- > > > >Fredrik Johansson > > > > > > > >W: +46 (0)8 725 5916 > > > >M: +46 (0)70 786 5035 > > > >mailto:Fredrik.Johansson@ipunplugged.com > > > >http://www.ipunplugged.com > > > > > > > > > > > > > > > > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 06:42: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 GAA19017 for ; Thu, 12 Oct 2000 06:42:31 -0400 (EDT) Received: from standards (47.234.32.16:4434) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2580@standards.nortelnetworks.com>; Thu, 12 Oct 2000 6:25:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3994 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 06:25:36 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2578@standards.nortelnetworks.com>; Thu, 12 Oct 2000 6:15:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18778; Thu, 12 Oct 2000 06:30:25 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200010121030.GAA18778@ietf.org> Date: Thu, 12 Oct 2000 06:30:25 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-rfc2344-bis-03.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 : Reverse Tunneling for Mobile IP, revised Author(s) : G. Montenegro Filename : draft-ietf-mobileip-rfc2344-bis-03.txt Pages : 31 Date : 11-Oct-00 Mobile IP uses tunneling from the home agent to the mobile node's care-of address, but rarely in the reverse direction. Usually, a mobile node sends its packets through a router on the foreign network, and assumes that routing is independent of source address. When this assumption is not true, it is convenient to establish a topologically correct reverse tunnel from the care-of address to the home agent. This document proposes backwards-compatible extensions to Mobile IP to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc2344-bis-03.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-rfc2344-bis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-rfc2344-bis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001011092153.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-rfc2344-bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-rfc2344-bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001011092153.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 08:15: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 IAA22725 for ; Thu, 12 Oct 2000 08:15:58 -0400 (EDT) Received: from standards (47.234.32.16:1268) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA26BA@standards.nortelnetworks.com>; Thu, 12 Oct 2000 7:58:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4334 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 07:58:55 -0400 Received: from aquarius.starnet.gov.sg (203.116.59.241:3532) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2685@standards.nortelnetworks.com>; Thu, 12 Oct 2000 7:48:53 -0400 Received: from pavilion ([172.16.140.23]) by aquarius.starnet.gov.sg (8.10.1/8.10.1) with SMTP id e9CC6pt29875 for ; Thu, 12 Oct 2000 20:06:53 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <000501c03444$3e743ec0$5c0c9cca@pavilion> Date: Thu, 12 Oct 2000 20:00:57 +0800 Reply-To: Brenda Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Brenda Subject: [MOBILE-IP] Subscribe To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Name: Yong Nyuk Ling Company: Defence Science & Technology Agency Address: 1 Depot Road Defence Technology TowerA #03-01J Singapore 109679 Tel: (O) 3732565 (H) 4712081 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 08: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 IAA23718 for ; Thu, 12 Oct 2000 08:36:10 -0400 (EDT) Received: from standards (47.234.32.16:1268) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA271E@standards.nortelnetworks.com>; Thu, 12 Oct 2000 8:19:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4515 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 08:19:23 -0400 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2716@standards.nortelnetworks.com>; Thu, 12 Oct 2000 8:09:22 -0400 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id FAA04157 for ; Thu, 12 Oct 2000 05:23:49 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id FAA15657 for ; Thu, 12 Oct 2000 05:23:49 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r4.mot.com with ESMTP for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 05:23:40 -0700 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id OAA07642 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM.DELIVER; Thu, 12 Oct 2000 14:23:00 +0200 (METDST) Received: from scooter.crm.mot.com (petrescu@riri.crm.mot.com [140.101.173.128]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id OAA07605 for ; Thu, 12 Oct 2000 14:22:59 +0200 (METDST) References: <001101c033ec$f1e096a0$a2388680@kwangwoon.ac.kr> Lines: 29 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: Date: Thu, 12 Oct 2000 14:22:58 +0200 Reply-To: petrescu@acm.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Alexandru Petrescu Subject: Re: [MOBILE-IP] MIPv6 node location detection To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: SungJin Lee's message of "Thu, 12 Oct 2000 10:37:12 +0900" SungJin Lee writes: > Q.1 A MIPv6 node moved to foreign link. The MIPv6 node restarts > the system there and receives router advertisements with > foreign network prefix. > > How do the MIPv6 node detect if it is located in foreign link ? > isn't it could be normal autoconfiguration as in the home llink ? Before moving save your home address somewhere; now land in a foreign net, get a new address, compare it to the previously saved and thus decide you're a foreigner. > > Q.2 A MIPv6 node located in it's home link. The node got an IP > address with stateless autoconfiguration. At a time the > router changed the home link prefix and multicast the router > advertisement with new prefix. After the home link prefix > ifetime expired or before the life time expired, it received > router advertisement with new prefix. > > Why doesn't the IPv6 node think it's located in foreign link > when it received ? isn't it possible the IPv6 node to think > it's moved to a foreign link and start MIPv6 process ? I would relate this to "renumbering". The draft-12 provides for renumbering while MN is away and I think that your case might be enunciated as a particular case of that. Alex From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 10: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 KAA27009 for ; Thu, 12 Oct 2000 10:37:26 -0400 (EDT) Received: from standards (47.234.32.16:2166) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA28B2@standards.nortelnetworks.com>; Thu, 12 Oct 2000 10:20:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5011 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 10:20:32 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA28B0@standards.nortelnetworks.com>; Thu, 12 Oct 2000 10:20:32 -0400 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA01478; Thu, 12 Oct 2000 08:35:18 -0600 (MDT) 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 HAA05341; Thu, 12 Oct 2000 07:35:17 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA08105; Thu, 12 Oct 2000 07:35:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Thu, 12 Oct 2000 07:33:01 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA X-To: Fredrik Johansson To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" > Hi Charlie > > That is true that the "Identification" field contains a challenge, but that > is from the mobile node towards the home agent. What we're looking for is > the oposite direction, from the home agent to the mobile node. > > In order to authenticate the user towards a Radius server using CHAP, a > challenge and a reponse is needed. Thus we need something like the MN-AAA > Authentication extension. > > By doing the authentication with a Radius server, the mobile node will only > need to keep one shared secret between the mobile node and ANY home agent on > the home network, since when authenticated with the Radius server, the home > agent will retrieve the subscriber data for that mobile node. This will make > home agent discovery easier since a new home agent can be deployed on the > home network without having to configure the mobile node with yet another > shared key. > Just out of curiosity, is there really a demand to do home agent allocation using RADIUS? I know of no such activity... Would it not instead make more sense to make use of RADIUS? If the Mobile Node has no SA with the HA, how will the MN-HA authentication extension be computed/generated? PatC PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 10:48: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 KAA27381 for ; Thu, 12 Oct 2000 10:48:43 -0400 (EDT) Received: from standards (47.234.32.16:2166) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA292F@standards.nortelnetworks.com>; Thu, 12 Oct 2000 10:29:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5165 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 10:29:56 -0400 Received: from stargate.ipunplugged.com (195.42.212.161:20050) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA292D@standards.nortelnetworks.com>; Thu, 12 Oct 2000 10:29:55 -0400 Received: from FREDRIKJPC ([192.168.4.218]) by stargate.ipunplugged.com (8.9.3/8.9.3) with SMTP id QAA07520; Thu, 12 Oct 2000 16:42:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Message-ID: Date: Thu, 12 Oct 2000 16:45:50 +0300 Reply-To: Fredrik Johansson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fredrik Johansson Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit See comments below... > -----Original Message----- > From: IP Routing for Wireless/Mobile Hosts (mobile-ip) > [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of > pcalhoun@eng.sun.com > Sent: den 12 oktober 2000 17:33 > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA > > > > Hi Charlie > > > > That is true that the "Identification" field contains a > challenge, but that > > is from the mobile node towards the home agent. What we're > looking for is > > the oposite direction, from the home agent to the mobile node. > > > > In order to authenticate the user towards a Radius server using CHAP, a > > challenge and a reponse is needed. Thus we need something like > the MN-AAA > > Authentication extension. > > > > By doing the authentication with a Radius server, the mobile > node will only > > need to keep one shared secret between the mobile node and ANY > home agent on > > the home network, since when authenticated with the Radius > server, the home > > agent will retrieve the subscriber data for that mobile node. > This will make > > home agent discovery easier since a new home agent can be > deployed on the > > home network without having to configure the mobile node with > yet another > > shared key. > > > Just out of curiosity, is there really a demand to do home agent > allocation > using RADIUS? I know of no such activity... Would it not instead make more > sense to make use of RADIUS? You're not using radius for home agent allocation, you use the regular home agent discovery mechanism, but the choosen home agent will receive the MN-HA key from the radius server. The mobile node will have the same secret will all the home agents within its home network. But don't pay to much attention to this, it was just an example where it can be used. what I'm intrested in is to be able to authenticate the client using RADIUS, i.e. there is a need for a challenge / response mechanism when using co-located foreign agent as well as when using a regular foreign agent. Rgds /Fredrik > > If the Mobile Node has no SA with the HA, how will the MN-HA > authentication > extension be computed/generated? > > PatC > > PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 10:48: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 KAA27392 for ; Thu, 12 Oct 2000 10:48:44 -0400 (EDT) Received: from standards (47.234.32.16:2166) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2957@standards.nortelnetworks.com>; Thu, 12 Oct 2000 10:33:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5212 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 10:33:20 -0400 Received: from sj-msg-core-2.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2952@standards.nortelnetworks.com>; Thu, 12 Oct 2000 10:33:15 -0400 Received: from msubbara-u10.cisco.com (msubbara-u10.cisco.com [161.44.59.58]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA05723; Thu, 12 Oct 2000 07:48:09 -0700 (PDT) Received: (msubbara@localhost) by msubbara-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA05681; Thu, 12 Oct 2000 10:48:00 -0400 (EDT) References: <4.3.2.7.2.20001010233421.00ce6cc0@omega.cisco.com> <39E539CE.7285BF59@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Message-ID: <20001012104800.A5638@cisco.com> Date: Thu, 12 Oct 2000 10:48:00 -0400 Reply-To: Madhavi Subbarao Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Madhavi Subbarao Subject: Re: [MOBILE-IP] MOBILE-IP] WG Last Call -(draft-ietf-mobileip-reg-tunnel-03.txt) X-To: Charlie Perkins To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <39E539CE.7285BF59@iprg.nokia.com>; from charliep@IPRG.NOKIA.COM on Wed, Oct 11, 2000 at 09:10:54PM -0700 Hi Charlie, I'm also perplexed with the introduction of new message types. Version 2 of your draft using extensions seemed like a more viable approach. Just curious...why wouldn't a MN be able to distinguish between a regional registration and home registration by extensions and flags? Maybe your concrete examples will shed some light. Thanks, Madhavi On Wed, Oct 11, 2000 at 09:10:54PM -0700, Charlie Perkins wrote: > Hello Gopal, > > > 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 > 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. > > It's not a simple issue. > > > > 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. > > > 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 > protocol needs to handle all cases as best it can do. > > > 2. What is the implementation of the current version of the Draft (not the previous versions)? > > We have an implementation. I have heard of others, which of course I don't > want to disclose without permission. Maybe we should try for an interoperability > test. > > Regards, > Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 11:24: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 LAA29729 for ; Thu, 12 Oct 2000 11:24:07 -0400 (EDT) Received: from standards (47.234.32.16:2166) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2A6B@standards.nortelnetworks.com>; Thu, 12 Oct 2000 11:07:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5553 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 11:07:12 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2A69@standards.nortelnetworks.com>; Thu, 12 Oct 2000 11:07:11 -0400 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 IAA05527; Thu, 12 Oct 2000 08:22:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9CFM1l21284; Thu, 12 Oct 2000 08:22:01 -0700 X-Virus-Scanned: Thu, 12 Oct 2000 08:22:01 -0700 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) smtpd66918n; Thu, 12 Oct 2000 08:21:57 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39E5D716.CAE4FBD4@iprg.nokia.com> Date: Thu, 12 Oct 2000 08:21:58 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA X-To: Fredrik Johansson To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Fredrik Johansson wrote: > > Hi Charlie > > That is true that the "Identification" field contains a challenge, but that > is from the mobile node towards the home agent. What we're looking for is > the oposite direction, from the home agent to the mobile node. This is done as follows: When the home agent sends a Registration Reply to the mobile node, that Registration Reply also has an Identification field. That field can have bits that the mobile node is required to return in the Identification field of the next Registration Request. Those bits would be the challenge you desire. > In order to authenticate the user towards a Radius server using CHAP, a > challenge and a reponse is needed. Thus we need something like the MN-AAA > Authentication extension. You need MN-AAA authentication extension if you are asking AAA to authorize the registration instead of the HA. I don't think there is any direct relationship between "challenge" and "MN-AAA". If you would like to arrange things so that the AAA supplies the bits to be inserted into the Identification field of the Registration Reply, I think that should work fine. It doesn't have to be standardized by the mobile-ip working group, but it might be a matter of interest to the aaa-wg. Regards, Charlie P. > > By doing the authentication with a Radius server, the mobile node will only > need to keep one shared secret between the mobile node and ANY home agent on > the home network, since when authenticated with the Radius server, the home > agent will retrieve the subscriber data for that mobile node. This will make > home agent discovery easier since a new home agent can be deployed on the > home network without having to configure the mobile node with yet another > shared key. > > Regards > /Fredrik > > > -----Original Message----- > > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > > Sent: den 12 oktober 2000 05:23 > > To: Fredrik Johansson > > Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA > > > > > > > > Hello, > > > > The statement has been made that the Registration Request does > > not contain a challenge. This isn't correct. The "Identification" field > > of the Registration Request message serves exactly the function > > of a challenge, from the standpoint of the home agent. I reckon it > > would be fairly easy to establish a security association between the > > mobile node and the home agent that would enable RADIUS to > > be used by the home agent, but there are details that would have > > to be worked out. > > > > Regards, > > Charlie P. > > > > > > Fredrik Johansson wrote: > > > > > Hi, > > > > > > the mobile node generates the challenge and send the request to the home > > > agent. The home agent will then include the same challenge in the > > > registration reply, is it up to the implementation of the > > co-located foreign > > > agent to remove the challenge before giving it to the mobile > > client so it is > > > not misstaken for a new challenge that can be sent in the > > registration reply > > > for use in the next registration? > > > > > > /Fredrik > > > > > > > -----Original Message----- > > > > From: IP Routing for Wireless/Mobile Hosts (mobile-ip) > > > > [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of > > Woo-June Kim > > > > Sent: den 6 oktober 2000 17:28 > > > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA > > > > > > > > > > > > Fredrik, > > > > > > > > The mobile node itself just generates a random number to use as > > > > the challenge. The response can only be correctly calculated by > > > > the mobile if it knows the correct key and algorithm. The AAA is > > > > simply using this fact to check the mobile's identity in a > > > > round-about manner. The challenge value itself is not something > > > > that must be generated in some special manner. > > > > > > > > cheers > > > > > > > > >BlankHi > > > > > > > > > >I have a question concerning how Challenge / Response is > > supposed to work > > > > >when a mobile node registers using a co-located foreign agent. > > > > > > > > > >Since the mobile node does not receive an advertisement with > > a challenge > > > > >from a FA it cannot calculate a response to be used in a MN-AAA > > > > >Authentication extension, i.e., the Home Agent cannot use a > > > > Radius server to > > > > >authenticate the MN. > > > > > > > > > >Have there been any thoughts in this area, or perhaps a > > solution in an > > > > >earlier thread that I've missed? Thankful for any pointers. > > > > > > > > > >Regards > > > > >/Fredrik > > > > >----------------------------------------- > > > > >Fredrik Johansson > > > > > > > > > >W: +46 (0)8 725 5916 > > > > >M: +46 (0)70 786 5035 > > > > >mailto:Fredrik.Johansson@ipunplugged.com > > > > >http://www.ipunplugged.com > > > > > > > > > > > > > > > > > > > > > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 12:43: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 MAA01784 for ; Thu, 12 Oct 2000 12:43:13 -0400 (EDT) Received: from standards (47.234.32.16:1103) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2BD1@standards.nortelnetworks.com>; Thu, 12 Oct 2000 12:22:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5896 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 12:22:37 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2BC4@standards.nortelnetworks.com>; Thu, 12 Oct 2000 12:12:36 -0400 Received: from snipe.prod.itd.earthlink.net ([207.217.121.233]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id LAA08512 for ; Thu, 12 Oct 2000 11:27:22 -0500 (CDT) Received: from mail.earthlink.net (1Cust57.tnt2.des-moines.ia.da.uu.net [63.11.130.57]) by snipe.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id JAA28678; Thu, 12 Oct 2000 09:26:26 -0700 (PDT) Received: from spyguide22@yahoo.com by cathy127@excite.com (8.8.5/8.6.5) with SMTP id GAA02774 for ; Thu, 12 Oct 2000 23:11:36 -0600 (EST) Message-ID: <> Date: Thu, 12 Oct 2000 23:11:36 EST Reply-To: 00914698@YAHOO.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: 00914698@YAHOO.COM Subject: [MOBILE-IP] The Net Detective. Learn how to snoop on Anyone! X-To: mikeh727@yahoo.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM READY TO KNOW? > > CONFIDENTIAL > > The SOFTWARE They Want BANNED In all 50 STATES. > Why? Because these secrets were never intended to reach your eyes... > Get the facts on anyone! > > Locate Missing Persons, find Lost Relatives, obtain Addresses > and Phone Numbers of old school friends, even Skip Trace Dead > Beat Spouses. This is not a Private Investigator, but a > sophisticated SOFTWARE program DESIGNED to automatically > CRACK YOUR CASE with links to thousands of Public Record databases. > > Find out SECRETS about your relatives, friends, enemies, > and everyone else! -- even your spouse! With the New, > INTERNET SPY AND YOU! > > It's absolutely astounding! Here's what you can learn: > > License plate number! > Get anyone's name and address with just a license plate number! > (Find that girl you met in traffic!) > > Driving record! > Get anyone's driving record > > Social security number! > Trace anyone by social security number! > > Address! > Get anyone's address with just a name! > > Unlisted phone numbers! > Get anyone's phone number with just a name-even unlisted numbers! > > Locate! > Long lost friends, relatives, a past lover who broke your heart! > > E-mail! > Send anonymous e-mail completely untraceable! > > Dirty secrets! > Discover dirty secrets your in-laws don't want you to know! > > Investigate anyone! > Use the sources that private investigators use (all on the Internet) > secretly! > > Ex-spouse! > Learn how to get information on an ex-spouse that will help you > win in court! (Dig up old skeletons) > > Criminal search-Backround check! > Find out about your daughters boyfriend! > (or her husband) > > Find out! > If you are being investigated! > > Neighbors! > Learn all about your mysterious neighbors! Find out what they > have to hide! > > People you work with! > Be astonished by what you'll learn about people you work with! > > Education verification! > Did he really graduate college? Find out! > > Internet Spy and You > Software will help you discover ANYTHING about anyone, with > clickable hyperlinks and no typing in Internet addresses! Just > insert the floppy disk and Go! > > You will be shocked and amazed by the secrets that can be > discovered about absolutely everyone! Find out the secrets > they don't want you to know! About others, about yourself! > > It's INCREDIBLE what you can find out using Internet Spy and You > and the Internet! You'll be riveted to your computer screen! > Get the software they're trying to ban! Before it's too late! > > LIMITED TIME OFFER: ORDER TODAY! > > Only $24.95 > > > We will RUSH YOU our Internet Spy and You software so you can > begin discovering all the secrets you ever wanted to know! > > You can know EVERYTHING about ANYONE with our Internet Spy and > You Software. Works with all browsers and all versions of AOL! > > ORDER TODAY: SEND ONLY $24.95 US CASH, CHECK, OR MONEY ORDER > (you may also send one of your own address labels > for accuracy if you have one.) > > ATTENTION ORDERS OUTSIDE THE US: You must ad $5 for shipping. > > > *Foreign money orders must be payable on a US BANK AND IN US FUNDS! > NO EXCEPTIONS! > > > > > DON'T WAIT TO GET STARTED... it's as easy as 1. 2. 3. > > > STEP 1 - Print the order form text below > > STEP 2 - Type or print your order information into the order form section > > STEP 3 - Mail order form and payment to the address below > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>Mail the portion below<<<<<<<<<<<<<<<<<<<< > > Send to: > > Consumer Resources > > PO BOX 283 > > Johnston, IA 50131 > > > U.S.A > > > > > > >>>>>>>>>>>>>>>>>>>>> Mail-in Order Form <<<<<<<<<<<<<<<<<<<<<<<< > > > > > Name: ______________________________ > > > Address: _____________________________ > > > City/State/Zip __________________________________________ > > > > > > > > > >>>>>>>>>>>>>>>>>>>>>> end of form <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > DISCLAIMER: The seller of this powerful software resource will not be > held responsible for how the purchaser chooses to use its resources. > > > > > To be removed from our mailing list please > send an email to m743@dcemail.com and put remove > in the subject. > Thank you From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 12:43: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 MAA01790 for ; Thu, 12 Oct 2000 12:43:13 -0400 (EDT) Received: from standards (47.234.32.16:1103) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2C03@standards.nortelnetworks.com>; Thu, 12 Oct 2000 12:24:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5974 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 12:24:15 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2C00@standards.nortelnetworks.com>; Thu, 12 Oct 2000 12:24:15 -0400 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 JAA11990; Thu, 12 Oct 2000 09:39:00 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9CGcwW27902; Thu, 12 Oct 2000 09:38:58 -0700 X-Virus-Scanned: Thu, 12 Oct 2000 09:38:58 -0700 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) smtpdN2FJI5; Thu, 12 Oct 2000 09:38:53 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <4.3.2.7.2.20001010233421.00ce6cc0@omega.cisco.com> <4.3.2.7.2.20001011220851.00cd3f00@omega.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39E5E91F.4B27FB47@iprg.nokia.com> Date: Thu, 12 Oct 2000 09:38:55 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] WG Last Call-(draft-ietf-mobileip-reg-tunnel-03.txt) X-To: Gopal Dommety X-cc: Annika Jonsson , Eva Gustafsson To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Gopal, I regret to say that this is a bit more additional work than I can schedule to do this week. I'll try to make this effort next week or so. Regards, Charlie P. 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 Thu Oct 12 14: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 OAB03833 for ; Thu, 12 Oct 2000 14:36:15 -0400 (EDT) Received: from standards (47.234.32.16:3145) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2D7C@standards.nortelnetworks.com>; Thu, 12 Oct 2000 14:19:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6457 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 14:19:22 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2D6E@standards.nortelnetworks.com>; Thu, 12 Oct 2000 14:09:21 -0400 Received: from lotofmail.lotof.com ([202.109.72.20]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id NAA09104 for ; Thu, 12 Oct 2000 13:24:12 -0500 (CDT) Received: from computer3 (pool0007.cvx28-bradley.dialup.earthlink.net [209.179.128.7]) by lotofmail.lotof.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id 4X0ZMAX4; Fri, 13 Oct 2000 02:19:08 +0800 Message-ID: <200010121824.NAA09104@hosaka.smallworks.com> Date: Thu, 12 Oct 2000 13:24:12 -0500 Reply-To: hedneyb@EAGLE.CA Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: hedneyb@EAGLE.CA Subject: [MOBILE-IP] GUARANTEED wat to instantly have EXCELLENT CREDIT!! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM $$$ GUARANTEED WAY TO INSTANTLY HAVE EXCELLENT CREDIT! $$$ Dear Friend, Give yourself the ADVANTAGE of enjoying life more with EXCELLENT CREDIT!! Over the past 8 years I have perfected a system called the Proven Credit Advantage Program. It's a guaranteed way for legally getting an excellent credit rating almost instantly. Here's how: If you have bad credit you will simply go through my easy 5 step program to quickly get a new, legal, unblemished credit file and establish Excellent Credit. If you don't have bad credit, but want to make your existing credit EXCELLENT, we will go straight to STEP 5. Step 1 - Because no two people in the United States have the same Social Security Number, Banks and Creditors access your credit file almost entirely by your SS#. You will not want to change your Social Security Number because it is extremely difficult to do so and you need it for your Employment, Taxes and Social Security Benefits. The FEDERAL PRIVACY ACT OF 1974 clearly states that only the Government and your employer can force you to use your SS#. Because of this law you are allowed to legally use another 9 digit number to use in place of your Social Security # on credit applications. The first day you become our client, you will receive your own number through the Employer Identification Number Program. You will need us for this because 95% of all Employer Identification Numbers, although 9 digits, do not look anything like Social Security Numbers and cannot be used on credit applications. We will legally get you an Employer Identification Number that fits in the same range of Social Numbers in use today. Because the Federal Laws do not require you to give your SS# to anyone besides your Employer and the Government, you can now legally use this number in place of your SS# on credit applications. Remember, your new number will only be used for new credit. Step 2 - No two people with the same name have the same mailing address, so you will need to obtain a new mailing address for use on your new credit file. A friend, relative or mailbox address in your area will be perfect. Step 3 - No two people with the same name have the same telephone numbers, so you will also need a new telephone number for use on your new credit file. A friend, relative, voice mail or pager will again work perfectly. Step 4 - With your new Social Security number, new address and new telephone number we will open your new credit file. It will now be totally impossible for any creditor to know anything about your past credit history. Step 5- To guarantee that you will quickly have EXCELLENT CREDIT, we will assist you in instantly adding UNLIMITED positive information to your credit file. This is an unknown way of adding real accounts to your new credit file to give you an Excellent Credit Rating in less than 30 days. As you know, the more positive information on your credit file, the more money banks will lend you. Countless clients of ours have credit lines over $100,000 because of our Proven Credit Advantage Program! When we are finished you will receive a copy of your credit file proving that you now have excellent credit! This will take less than 30 days. You will now be able to easily qualify for ANY credit you apply for! To be on the road to EXCELLENT CREDIT simply send us your name, complete mailing address including zip code and telephone number (optional), along with a check or money order payable to American Financial Services Inc. for $29.95. Send to: American Financial Services Inc. Attn: Mike Robbins 311 N. Robertson Blvd. Suite 625 Beverly Hills, CA 90210 All necessary paperwork along with a telephone number to contact us for assistance will be priority mailed to you within 3 business days. $$$$ RISK FREE DOUBLE YOUR MONEY BACK GUARANTEE!! $$$$ My Proven Credit Advantage Program unconditionally guarantees you will qualify for personal loans, business loans, credit cards, auto loans, home loans and any other credit you apply for! If you are not able to qualify for credit after using my program, simply return your Proven Credit Advantage Program along with your denial letter and your $29.95 investment will be refunded DOUBLE! That's a $59.90 refund if this doesn't work like I say! I make this guarantee to you because the Proven Credit Advantage Program has already helped over 15,000 people just like you. I KNOW it works - all you need to do is sign up TODAY! I truly look forward to making you another SATISFIED CLIENT!! ................................................................................ Yes! I deserve excellent credit. Please enroll me in the Proven Credit Advantage Program. Enclosed is my check/money order for $29.95. The following information is for our records only and does not need to be your new credit file information. First Name______________________________ Last Name________________________________ Address__________________________________ City_____________________________________ State_______________Zip__________________ Telephone(optional)______________________ If you would prefer to download your Proven Credit Advantage Program, include your e-mail address below and we will e-mail you a download location upon receipt of your order. e-mail___________________________________ Send $29.95 to: American Financial Services Inc. Attn: Mike Robbins 311 N. Robertson Blvd. Suite 625 Beverly Hills, CA 90210 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 18:58: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 SAA07362 for ; Thu, 12 Oct 2000 18:58:21 -0400 (EDT) Received: from standards (47.234.32.16:1484) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2F53@standards.nortelnetworks.com>; Thu, 12 Oct 2000 18:41:31 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7046 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 18:41:31 -0400 Received: from qhars002.nortel.com (47.101.112.102:44318) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2F4B@standards.nortelnetworks.com>; Thu, 12 Oct 2000 18:31:31 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Thu, 12 Oct 2000 23:43:22 +0100 Received: from zrchs148 by smtprch1.nortel.com; Thu, 12 Oct 2000 16:48:56 -0500 Received: from zrchb200.us.nortel.com (actually zrchb200) by zrchs148; Thu, 12 Oct 2000 16:40:59 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id <4VMC9Q94>; Thu, 12 Oct 2000 16:48:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03496.2CB322D0" Message-ID: Date: Thu, 12 Oct 2000 16:48:36 -0500 Reply-To: Sarvesh Sharma Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Sarvesh Sharma Subject: [MOBILE-IP] Unsubscribe To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM ------_=_NextPart_001_01C03496.2CB322D0 Content-type: text/plain; charset="iso-8859-1" Header says all. Regards, -Sarvesh ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sarvesh Sharma Manager Dept: 2N22 - CDMA System Performance * (972) 684-0654 * ESN 444-0654 * sarvesh@nortelnetworks.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------_=_NextPart_001_01C03496.2CB322D0 Content-type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Unsubscribe

Header says all.

Regards,

-Sarvesh

    = ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Sarvesh Sharma
    = Manager
    = Dept: 2N22 - CDMA = System Performance
    (  (972) 684-0654    (  ESN 444-0654
    . sarvesh@nortelnetworks.com
    = ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


------_=_NextPart_001_01C03496.2CB322D0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 19:33: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 TAA07869 for ; Thu, 12 Oct 2000 19:33:29 -0400 (EDT) Received: from standards (47.234.32.16:3584) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2FB9@standards.nortelnetworks.com>; Thu, 12 Oct 2000 19:16:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7187 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 19:16:48 -0400 Received: from gremlin.ics.uci.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2FB7@standards.nortelnetworks.com>; Thu, 12 Oct 2000 19:06:48 -0400 Received: from lassie ( magda-dell-lt.ics.uci.edu [128.195.4.112] ) by gremlin-relay.ics.uci.edu id aa20499 for ; 12 Oct 2000 16:21 PDT MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C0_01C03468.DC9ACEB0" 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 Message-ID: <00c301c034a3$89352910$7004c380@lassie> Date: Thu, 12 Oct 2000 16:24:14 -0700 Reply-To: Magda El Zarki Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Magda El Zarki Organization: UC, Irvine Subject: [MOBILE-IP] Unsubscribe both my email addresses To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_00C0_01C03468.DC9ACEB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable please also unsbuscribe my other email address: magda@ee.upenn.edu thanks ------=_NextPart_000_00C0_01C03468.DC9ACEB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
please also unsbuscribe my other email=20 address:
magda@ee.upenn.edu
thanks
------=_NextPart_000_00C0_01C03468.DC9ACEB0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 23:47: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 XAA15209 for ; Thu, 12 Oct 2000 23:47:41 -0400 (EDT) Received: from standards (47.234.32.16:3616) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3089@standards.nortelnetworks.com>; Thu, 12 Oct 2000 23:30:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7456 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 23:30:52 -0400 Received: from mail3.mia.bellsouth.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3085@standards.nortelnetworks.com>; Thu, 12 Oct 2000 23:20:51 -0400 Received: from pllt1078w2k (adsl-63-238-239.mia.bellsouth.net [208.63.238.239]) by mail3.mia.bellsouth.net (3.3.5alt/0.75.2) with SMTP id XAA05622; Thu, 12 Oct 2000 23:35:44 -0400 (EDT) References: <00c301c034a3$89352910$7004c380@lassie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0062_01C034A4.C7A3B710" 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 Message-ID: <006501c034c6$50f24ec0$efee3fd0@comm.mot.com> Date: Thu, 12 Oct 2000 23:33:09 -0400 Reply-To: Fernando Guerrero Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fernando Guerrero Subject: [MOBILE-IP] Unsubscribe To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0062_01C034A4.C7A3B710 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Unsubscriber this email address: guerrero@mediaone.net ------=_NextPart_000_0062_01C034A4.C7A3B710 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Unsubscriber this email address: guerrero@mediaone.net ------=_NextPart_000_0062_01C034A4.C7A3B710-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 01:39: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 BAA21046 for ; Fri, 13 Oct 2000 01:39:10 -0400 (EDT) Received: from standards (47.234.32.16:3085) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3252@standards.nortelnetworks.com>; Fri, 13 Oct 2000 1:22:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8050 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 01:22:16 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA324D@standards.nortelnetworks.com>; Fri, 13 Oct 2000 1:12:15 -0400 Received: from correoweb.qs.net (tiendas.grupoagm.com [194.179.45.185]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id AAA12455; Fri, 13 Oct 2000 00:27:06 -0500 (CDT) Received: from [63.21.37.28] by correoweb.qs.net (Post.Office MTA v3.5.3 release 223 ID# 0-68660U700L100S0V35) with SMTP id net; Fri, 13 Oct 2000 04:37:11 +0200 Received: from by 1Cust28.tnt4.mia1.da.uu.net with ESMTP; Wed, 11 Oct 2000 21:59:02 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <00007e8a2612$000010ab$00007e31@> Date: Wed, 11 Oct 2000 21:58:55 -0400 Reply-To: giamma@WIN.NET Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: giamma@WIN.NET Subject: [MOBILE-IP] NEW DEBIT CARD...NO PROOF OF ID NEEDED 4517 X-To: Undisclosed.Recipients@hosaka.smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: quoted-printable NEW DEBIT CARD...NO BANK ACCOUNT NEEDED NO PROOF OF ID NEEDED USE FOR FOR TEENS OR COLLEGE KIDS NO CREDIT CHECK SHOP ANONYMOUSLY.... CARD NEEDS NO ID The comCash Card is the world's first non-qualifying, cash-based debit car= d available outside the traditional banking system. The card is specifically designed to allow consumers to purchase goods and services with the same ease of use as a credit card, but with far greater security, anonymity, flexibility, and savings. Sign Up At http://www.getacashcard.com/mail1.asp The .comCash card acts as your own personal virtual bank. Key advantages of the .comCash card include: No identification required to have and use a .comCash card No credit required No credit approval needed No bank account needed No documentation of purchases - complete anonymity Secure transaction record of your purchases available only to you Safe, fast, easy to use The Cash card allows you to make purchases with total ease and with complete anonymity. Sign Up At http://www.getacashcard.com/mail1.asp Under Bill 1618 TITLE III passed by the 105th U.S. Congress This letter ca= nnot be considered Spam as long as we include: Contact information & a Remove Lin= k. TO REMOVE CLICK ON mailto:nocardit2@yahoo.com RSVP Marketing, PO Box 630692 Miami Florida 33163-0692 Toll Free 888=3D900=3D7336

DO NOT USE REPLY OR FROM ADDRESS FOR REMOVAL All our mailings are sent =

complying with the proposed United States Federal requirements for comm= ercial e-mail:

Section 301 Paragraph (a)(2)(C) of S. 618.

TO REMOVE = CLICK ON mailto:nocardit2@yahoo.com?Subject=3DRemoveDoc

Toll Free telep= hone number and company information is available at end of message.

++++= ++++++++++++++++++++++++++++++++++++++++++++++++++++++++

=

From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 02:34: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 CAA00075 for ; Fri, 13 Oct 2000 02:34:21 -0400 (EDT) Received: from standards (47.234.32.16:2256) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA330A@standards.nortelnetworks.com>; Fri, 13 Oct 2000 2:17:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8300 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 02:17:25 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3308@standards.nortelnetworks.com>; Fri, 13 Oct 2000 2:07:24 -0400 Received: from mail.controlled-demolition.co.uk (mail.controlled-demolition.co.uk [195.92.182.18]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id BAA12732; Fri, 13 Oct 2000 01:22:15 -0500 (CDT) Received: from 209.178.164.240 [209.178.164.240] by mail.controlled-demolition.co.uk (SMTPD32-5.01) id A6A463CB021A; Fri, 13 Oct 2000 07:07:32 +0100 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <00000efe7b6b$000062b8$00000a57@> Date: Thu, 12 Oct 2000 23:07:16 -0700 Reply-To: tersian@SPRINTMAIL.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: tersian@SPRINTMAIL.COM Subject: [MOBILE-IP] Accept Credit Cards - Free Setup 2647 X-To: Undisclosed.Recipients@hosaka.smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: quoted-printable Quick Application
HOW TO SUBSTANTIALLY INCREASE SALES

Easily accept major credit cards right away!

Act now and all Setup & App. fees waived

Merchant Status will help you increase sales by an
incredible 50% to 400%. Stop losing valuable sales!

With one phone call you can be:

Accepting all major credit cards!
Accepting checks over the net or by Fax!
Accepting real time processing for member sites!
Gaining costumer loyalty and trust!
Close the sale now. No more wondering if "The check
is in the mail"

We specialize in helping those entrepreneurs who
are just starting out: no credit, poor credit, or
even if you have great credit.

Almost everyone is approved!

For the next 5 days we will waive all Setup & App.
fees! (other companies charge $200 to $500 to set up)






Our 30 second application

Fill= out this short form to receive your free information.

Or, call our courteous customer care reps Now at 800-561-3128.
Leave your Name, Phone Number and Best Time To Call.
1. Please en= ter your full name:
2. Please en= ter your phone number:
(xxx-xxx-xxxx)
Home Work
3. What is t= he best time to phone you?
4. State or = Province where you live?
5. Country w= here you live?
6. Please en= ter your email address:
       

If you received this in error or would like to be
removed from our list, PLEASE CLICK HERE


From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 07:35: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 HAA03100 for ; Fri, 13 Oct 2000 07:35:45 -0400 (EDT) Received: from standards (47.234.32.16:1241) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA34FD@standards.nortelnetworks.com>; Fri, 13 Oct 2000 7:18:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8935 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 07:18:39 -0400 Received: from anchor-post-31.mail.demon.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA34FB@standards.nortelnetworks.com>; Fri, 13 Oct 2000 7:18:38 -0400 Received: from panasonic-pmdc.demon.co.uk ([194.222.202.84] helo=panasonic-pmdc) by anchor-post-31.mail.demon.net with esmtp (Exim 2.12 #1) id 13k35g-00005q-0V for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 12:33:32 +0100 Received: from 100.100.101.233 by panasonic-pmdc ([100.100.101.232] running VPOP3) with SMTP for ; Fri, 13 Oct 2000 12:23:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-Server: VPOP3 V1.4.0b - Registered to: Panasonic PMDC Message-ID: <000001c03506$be23b160$e9656464@pc1233> Date: Fri, 13 Oct 2000 12:14:23 +0100 Reply-To: gavin.button@panasonic-pmdc.co.uk Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gavin Button Subject: [MOBILE-IP] Mobile IP Routing Implementation Issue To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi All, I am researching and implementing MobileIP as defined in RFC2002, October 1996 and have a question. My configuration within a private network is as follows: Mobile Host: IP address 100.100.101.239 Home Agent: IP address 100.100.101.233 Foreign Agent: IP Address 10.0.0.2 (all subnet masks are 255.255.255.0) The Mobile Host visits the Foreign Agent network and registers the Care of Address (10.0.0.2) with the Home Agent. Once registration has completed I ping the Mobile Host from a machine on its Home Network (100.100.100.207). The ping request reaches the Mobile Host succesfully, at which point the TCP/IP stack attempts a broadcast ARP Request to determine the MAC address of 100.100.101.207, which it believes to be on the same network, this fails so the ping reply is never generated. The section in RFC 2002 on Mobile Host Datagram Routing (4.2.1) states that a default router should be selected for the foreign network. If I do this and set the deafult router to be 10.0.0.1 (router between the two networks) then it still does generates an ARP request for 100.100.101.207. I believe this is because the TCP/IP stack doesnt recognise the router, 10.0.0.1, as being on the same network as its IP Address, 100.100.101.239, so does not consider it for sending the ping reply to. Can anyone explain what I might be doing wrong? Thanks in Advance, Gavin Button From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 08:25: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 IAA04134 for ; Fri, 13 Oct 2000 08:25:35 -0400 (EDT) Received: from standards (47.234.32.16:1241) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA362F@standards.nortelnetworks.com>; Fri, 13 Oct 2000 8:08:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9320 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 08:08:40 -0400 Received: from anchor-post-30.mail.demon.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA362D@standards.nortelnetworks.com>; Fri, 13 Oct 2000 8:08:39 -0400 Received: from panasonic-pmdc.demon.co.uk ([194.222.202.84] helo=panasonic-pmdc) by anchor-post-30.mail.demon.net with esmtp (Exim 2.12 #1) id 13k3s5-000Hxv-0U; Fri, 13 Oct 2000 13:23:33 +0100 Received: from 100.100.101.233 by panasonic-pmdc ([100.100.101.232] running VPOP3) with SMTP; Fri, 13 Oct 2000 13:20:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-Server: VPOP3 V1.4.0b - Registered to: Panasonic PMDC Message-ID: <000101c0350e$9d68cfc0$e9656464@pc1233> Date: Fri, 13 Oct 2000 13:10:44 +0100 Reply-To: gavin.button@panasonic-pmdc.co.uk Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gavin Button Subject: Re: [MOBILE-IP] Mobile IP Routing Implementation Issue X-cc: Bill Manning To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200010131159.EAA24913@zed.isi.edu> Content-Transfer-Encoding: 7bit % % Hi All, % % I am researching and implementing MobileIP as defined in RFC2002, October % 1996 and have a question. % % My configuration within a private network is as follows: % Mobile Host: IP address 100.100.101.239 % Home Agent: IP address 100.100.101.233 % Foreign Agent: IP Address 10.0.0.2 % (all subnet masks are 255.255.255.0) % % Can anyone explain what I might be doing wrong? % % Gavin Button First off, network 100.0.0.0/8 is -NOT- a private network number. Ok, maybe the use of 'private network' was not quite correct. What I meant is that is a local network I have setup up for testing purposes only, which is not connected to the internet. Gavin From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 08:32: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 IAA04333 for ; Fri, 13 Oct 2000 08:32:49 -0400 (EDT) Received: from standards (47.234.32.16:1241) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3662@standards.nortelnetworks.com>; Fri, 13 Oct 2000 8:12:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9316 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 08:12:54 -0400 Received: from explore.kwangwoon.ac.kr (128.134.70.30:58292) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA362A@standards.nortelnetworks.com>; Fri, 13 Oct 2000 8:02:53 -0400 Received: from eos (eos.kwangwoon.ac.kr [128.134.56.162]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id VAA25206 for ; Fri, 13 Oct 2000 21:14:50 +0900 (KST) References: <001101c033ec$f1e096a0$a2388680@kwangwoon.ac.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <002c01c0350f$c6b4e7a0$a2388680@kwangwoon.ac.kr> Date: Fri, 13 Oct 2000 21:19:03 +0900 Reply-To: SungJin Lee Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: SungJin Lee Subject: Re: [MOBILE-IP] MIPv6 node location detection To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id IAA04333 What is the difference between two advertisement below ? - Renumbered home link router advertisement - Router advertisement in a foreign link My question is why the mobile node don't just add the new address in MN's address list. How do the MN decide whether it start MIPv6 process or autoconfiguration process for renumbered home link address. What if the all home addresses in the list have expired before the MN get FA's router advertisement, can the MN still use the expired address record in it's system ? I also can't find RFC or draft which define exactly address list in a MIPv6 MN. A IPv6 node have a address list and every prefix has lifetime. Please give me some advice on it. ----- Original Message ----- From: "Alexandru Petrescu" To: Sent: Thursday, October 12, 2000 9:22 PM Subject: Re: [MOBILE-IP] MIPv6 node location detection : SungJin Lee writes: : > Q.1 A MIPv6 node moved to foreign link. The MIPv6 node restarts : > the system there and receives router advertisements with : > foreign network prefix. : > : > How do the MIPv6 node detect if it is located in foreign link ? : > isn't it could be normal autoconfiguration as in the home llink ? : : Before moving save your home address somewhere; now land in a foreign : net, get a new address, compare it to the previously saved and thus : decide you're a foreigner. : : > : > Q.2 A MIPv6 node located in it's home link. The node got an IP : > address with stateless autoconfiguration. At a time the : > router changed the home link prefix and multicast the router : > advertisement with new prefix. After the home link prefix : > ifetime expired or before the life time expired, it received : > router advertisement with new prefix. : > : > Why doesn't the IPv6 node think it's located in foreign link : > when it received ? isn't it possible the IPv6 node to think : > it's moved to a foreign link and start MIPv6 process ? : : I would relate this to "renumbering". The draft-12 provides for : renumbering while MN is away and I think that your case might be : enunciated as a particular case of that. : : Alex : From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 09:45: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 JAA05506 for ; Fri, 13 Oct 2000 09:45:12 -0400 (EDT) Received: from standards (47.234.32.16:1303) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3846@standards.nortelnetworks.com>; Fri, 13 Oct 2000 9:27:57 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9975 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 09:27:56 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:48673) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3842@standards.nortelnetworks.com>; Fri, 13 Oct 2000 9:27:55 -0400 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 XAA20232; Fri, 13 Oct 2000 23:39:18 +1000 (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 AAA06624; Sat, 14 Oct 2000 00:41:37 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id <4XFQPXLS>; Sat, 14 Oct 2000 00:41:45 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613C6A@eaubrnt018.epa.ericsson.se> Date: Sat, 14 Oct 2000 00:41:45 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: SungJin Lee X-cc: ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > What is the difference between two advertisement below ? > - Renumbered home link router advertisement > - Router advertisement in a foreign link > > My question is why the mobile node don't just add the new address > in MN's address list. How do the MN decide whether it start MIPv6 > process or autoconfiguration process for renumbered home link address. > What if the all home addresses in the list have expired before the MN > get FA's router advertisement, can the MN still use the expired address > record > in it's system ? > => I think you're certainly asking the right question but perhaps to the wrong mailing list :) If I understand you correctly, you're saying that while the MN is at Home, if a new advertisement is received with a new prefix, how does it know that this is not another foreign subnet. Well based on my rusty knowledge of ND and stateless address configuration, it doesnt know. But I don't think that this is strictly a MIP issue. While you're at home MIP does not do anything for you. So that's why I'll cc IPng on this to see if someone can give you a better answer, or maybe I missed something here. BTW FA's do not exist in MIPv6. > I also can't find RFC or draft which define exactly address list in a > MIPv6 MN. A IPv6 node have a address list and every prefix has lifetime. > Please give me some advice on it. > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 09:53: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 JAA05702 for ; Fri, 13 Oct 2000 09:53:15 -0400 (EDT) Received: from standards (47.234.32.16:1303) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3895@standards.nortelnetworks.com>; Fri, 13 Oct 2000 9:34:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10075 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 09:34:43 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:48740) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3892@standards.nortelnetworks.com>; Fri, 13 Oct 2000 9:34:42 -0400 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 XAA20354; Fri, 13 Oct 2000 23:46:07 +1000 (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 AAA07045; Sat, 14 Oct 2000 00:48:27 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id <4XFQPX3R>; Sat, 14 Oct 2000 00:48:35 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613C6B@eaubrnt018.epa.ericsson.se> Date: Sat, 14 Oct 2000 00:48:35 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] MIPv6 node location detection X-cc: ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Sorry forgot to cc IPng > -----Original Message----- > From: Hesham Soliman (EPA) [SMTP:Hesham.Soliman@ERICSSON.COM.AU] > Sent: Saturday, 14 October 2000 12:42 > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] MIPv6 node location detection > > > What is the difference between two advertisement below ? > > - Renumbered home link router advertisement > > - Router advertisement in a foreign link > > > > My question is why the mobile node don't just add the new address > > in MN's address list. How do the MN decide whether it start MIPv6 > > process or autoconfiguration process for renumbered home link address. > > What if the all home addresses in the list have expired before the MN > > get FA's router advertisement, can the MN still use the expired address > > record > > in it's system ? > > > => I think you're certainly asking the right question but > perhaps to the wrong mailing list :) > If I understand you correctly, you're saying that while the > MN is at Home, if a new advertisement is received with a new > prefix, how does it know that this is not another foreign subnet. > Well based on my rusty knowledge of ND and stateless address > configuration, it doesnt know. But I don't think that this is > strictly > a MIP issue. While you're at home MIP does not do anything > for you. So that's why I'll cc IPng on this to see if someone can > give you a better answer, or maybe I missed something here. > BTW FA's do not exist in MIPv6. > > > > > > > I also can't find RFC or draft which define exactly address list in a > > MIPv6 MN. A IPv6 node have a address list and every prefix has > lifetime. > > Please give me some advice on it. > > > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 09:53: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 JAA05706 for ; Fri, 13 Oct 2000 09:53:16 -0400 (EDT) Received: from standards (47.234.32.16:1303) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA389C@standards.nortelnetworks.com>; Fri, 13 Oct 2000 9:35:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9947 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 09:35:18 -0400 Received: from qhars002.nortel.com (47.101.112.102:59975) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA382B@standards.nortelnetworks.com>; Fri, 13 Oct 2000 9:25:18 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Fri, 13 Oct 2000 14:39:35 +0100 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Fri, 13 Oct 2000 08:39:38 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id <4VMC9Y38>; Fri, 13 Oct 2000 08:39:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0351A.FF55AA80" Message-ID: <9A9367D1556AD21182C40000F80930AB02D03882@crchy28b.us.nortel.com> Date: Fri, 13 Oct 2000 08:39:23 -0500 Reply-To: Vivek Sakhuja Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Vivek Sakhuja Subject: Re: [MOBILE-IP] Unsubscribe 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_01C0351A.FF55AA80 Content-Type: text/plain ------_=_NextPart_001_01C0351A.FF55AA80 Content-Type: text/html RE: [MOBILE-IP] Unsubscribe
------_=_NextPart_001_01C0351A.FF55AA80-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 10:07: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 KAA06349 for ; Fri, 13 Oct 2000 10:07:05 -0400 (EDT) Received: from standards (47.234.32.16:1303) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3976@standards.nortelnetworks.com>; Fri, 13 Oct 2000 9:49:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10361 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 09:49:53 -0400 Received: from qhars002.nortel.com (47.101.112.102:63453) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3974@standards.nortelnetworks.com>; Fri, 13 Oct 2000 9:49:53 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Fri, 13 Oct 2000 15:03:48 +0100 Received: from zrchs148 by smtprch1.nortel.com; Fri, 13 Oct 2000 09:03:10 -0500 Received: from zrchb200.us.nortel.com (actually zrchb200) by zrchs148; Fri, 13 Oct 2000 08:55:11 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id <4VMC9Z31>; Fri, 13 Oct 2000 09:02:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0351E.478A7080" Message-ID: <36FA02BD7083D411BC9E0000F8073E438CEEE6@crchy271.us.nortel.com> Date: Fri, 13 Oct 2000 09:02:53 -0500 Reply-To: Glenn Morrow Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Glenn Morrow Subject: Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup port in IPv6"draft] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM ------_=_NextPart_001_01C0351E.478A7080 Content-type: text/plain; charset="us-ascii" > -----Original Message----- > From: Fred Baker [SMTP:fred@CISCO.COM] > Sent: Wednesday, October 11, 2000 12:30 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of > "MobilitySup port in IPv6"draft] > > >It seems that most people are supportive of limiting the filtering to the > >edges of the network. This would help mobility immensely in that home > >addresses could be used as the source address and remove a bunch of > issues > >with tunneling. > Have you gotten any operators to say that? You haven't made much of a case > until you have operational support. > I have spoken with a few and most agree that it takes only one dissenter to eliminate the possibility - looks like the use of the COA as the source throughout the network is definitely needed. ------_=_NextPart_001_01C0351E.478A7080 Content-type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of = "MobilitySup port in IPv6"draft]

    -----Original Message-----
    From:   Fred Baker [SMTP:fred@CISCO.COM]
    Sent:   Wednesday, October 11, 2000 12:30 PM
    To:     MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: [MOBILE-IP] [Fwd: Re: = [MOBILE-IP] New version of "MobilitySup port  in = IPv6"draft]

    >It seems that most people are = supportive of limiting the filtering to the
    >edges of the network. This would = help mobility immensely in that home
    >addresses could be used as the = source address and remove a bunch of issues
    >with tunneling.
    Have you gotten any operators to say = that? You haven't made much of a case
    until you have operational = support.

    I have spoken with a = few and most agree that it takes only one dissenter to eliminate the = possibility - looks like the use of the COA as the source throughout = the network is definitely needed.

------_=_NextPart_001_01C0351E.478A7080-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 10:25: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 KAA06585 for ; Fri, 13 Oct 2000 10:25:07 -0400 (EDT) Received: from standards (47.234.32.16:1303) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA39FF@standards.nortelnetworks.com>; Fri, 13 Oct 2000 10:08:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10479 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 10:08:01 -0400 Received: from iol.unh.edu (mars.iol.unh.edu) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA39D1@standards.nortelnetworks.com>; Fri, 13 Oct 2000 9:58:00 -0400 Received: from localhost (jfl@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id KAA29019; Fri, 13 Oct 2000 10:14:26 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Fri, 13 Oct 2000 10:14:26 -0400 Reply-To: "John F. Leser" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "John F. Leser" Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: "Hesham Soliman (EPA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A50C613C6A@eaubrnt018.epa.ericsson.se> On Sat, 14 Oct 2000, Hesham Soliman (EPA) wrote: > > What is the difference between two advertisement below ? > > - Renumbered home link router advertisement > > - Router advertisement in a foreign link > > > > My question is why the mobile node don't just add the new address > > in MN's address list. How do the MN decide whether it start MIPv6 > > process or autoconfiguration process for renumbered home link address. > > What if the all home addresses in the list have expired before the MN > > get FA's router advertisement, can the MN still use the expired address > > record > > in it's system ? > > > => I think you're certainly asking the right question but > perhaps to the wrong mailing list :) > If I understand you correctly, you're saying that while the > MN is at Home, if a new advertisement is received with a new > prefix, how does it know that this is not another foreign subnet. > Well based on my rusty knowledge of ND and stateless address > configuration, it doesnt know. But I don't think that this is > strictly > a MIP issue. While you're at home MIP does not do anything > for you. So that's why I'll cc IPng on this to see if someone can > give you a better answer, or maybe I missed something here. > BTW FA's do not exist in MIPv6. > Reading through section 10.4 of the MIPv6 draft (version 12), I get the impression that: 1. Movement detection is not a simple problem to solve. The draft doesn't really specifiy what method should be used. 2. Seeing an adverisement from a router with a different prefix is not a good way to detect movement. The preferred movement detection method seems to be loss of reachability of the MN's default router, which is noticed through neighbor unreachability detection and/or use of the router advertisement interval option. > > > > > > I also can't find RFC or draft which define exactly address list in a > > MIPv6 MN. A IPv6 node have a address list and every prefix has lifetime. > > Please give me some advice on it. > > > > > > > You may want to take a look at section 5.2 of RFC 2462, which mentions the address list. I hope this is helpful. ------------------------------------------------------------------- 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 Fri Oct 13 10:33: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 KAA06697 for ; Fri, 13 Oct 2000 10:33:06 -0400 (EDT) Received: from standards (47.234.32.16:1303) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3A43@standards.nortelnetworks.com>; Fri, 13 Oct 2000 10:14:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10615 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 10:14:19 -0400 Received: from stargate.ipunplugged.com (195.42.212.161:21305) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3A41@standards.nortelnetworks.com>; Fri, 13 Oct 2000 10:14:18 -0400 Received: from FREDRIKJPC ([192.168.4.218]) by stargate.ipunplugged.com (8.9.3/8.9.3) with SMTP id QAA16172; Fri, 13 Oct 2000 16:27:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Message-ID: Date: Fri, 13 Oct 2000 16:30:34 +0300 Reply-To: Fredrik Johansson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fredrik Johansson Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA X-To: charliep@iprg.nokia.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <39E5D716.CAE4FBD4@iprg.nokia.com> Content-Transfer-Encoding: 7bit > -----Original Message----- > From: charliep@iprg.nokia.com [mailto:charliep@iprg.nokia.com] > Sent: den 12 oktober 2000 18:22 > To: Fredrik Johansson > Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA > > > Fredrik Johansson wrote: > > > > Hi Charlie > > > > That is true that the "Identification" field contains a > challenge, but that > > is from the mobile node towards the home agent. What we're > looking for is > > the oposite direction, from the home agent to the mobile node. > > This is done as follows: > > When the home agent sends a Registration Reply to the mobile node, > that Registration Reply also has an Identification field. That > field can have bits that the mobile node is required to return in > the Identification field of the next Registration Request. > Those bits would be the challenge you desire. I don't agree, if you're using timestamps, the mobile node will set its time in the low-order 32 bits and a random number in the high-order 32 bits. The home agent will return the 64 bits as is if the request is within the timeframe or it will return the low-order 32 bits from the request and its own time in the high-order 32 bits if outside the timeframe. If rejected the mobile node will adjust its time and send a new request with it new time in the low-order 32 bits and a new random number in the high-order 32 bits. If the home agent can act as follows, the challenge extension is not needed when registered as co-located foreign agent: 1. When a challenge extension is present in the request, it will use it as the challenge to use toghether with the MN-AAA authentication extension. I.e. the registration is via a foreign agent. 2. If no challenge extension is present, the home agent will use the high order 32 bits from the identification field as challenge toghether with the MN-AAA authentication extension. Thus the mobile node will create its own challenge. The important thing is that both nodes know which field to use as a challenge when trying to verify the authenticity of the user. The mobile node is the only one that can know if it is registered as a co-located foreign agent or not. > > > In order to authenticate the user towards a Radius server using CHAP, a > > challenge and a reponse is needed. Thus we need something like > the MN-AAA > > Authentication extension. > > You need MN-AAA authentication extension if you are asking AAA to > authorize the registration instead of the HA. I don't think there > is any direct relationship between "challenge" and "MN-AAA". If you > would like to arrange things so that the AAA supplies the bits to > be inserted into the Identification field of the Registration Reply, > I think that should work fine. It doesn't have to be standardized > by the mobile-ip working group, but it might be a matter of interest > to the aaa-wg. I don't know, I believe there is a relation since ? 6 in the challenge/response draft states "If the mobile node does not include a Mobile-Foreign Authentication [8] extension, then it MUST include the MN-AAA Authentication extension whenever the Challenge extension is present," But that is no problem if the home agent treats the request according to the suggestion above. Regards /Fredrik > > Regards, > Charlie P. > > > > > > By doing the authentication with a Radius server, the mobile > node will only > > need to keep one shared secret between the mobile node and ANY > home agent on > > the home network, since when authenticated with the Radius > server, the home > > agent will retrieve the subscriber data for that mobile node. > This will make > > home agent discovery easier since a new home agent can be > deployed on the > > home network without having to configure the mobile node with > yet another > > shared key. > > > > Regards > > /Fredrik > > > > > -----Original Message----- > > > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > > > Sent: den 12 oktober 2000 05:23 > > > To: Fredrik Johansson > > > Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA > > > > > > > > > > > > Hello, > > > > > > The statement has been made that the Registration Request does > > > not contain a challenge. This isn't correct. The > "Identification" field > > > of the Registration Request message serves exactly the function > > > of a challenge, from the standpoint of the home agent. I reckon it > > > would be fairly easy to establish a security association between the > > > mobile node and the home agent that would enable RADIUS to > > > be used by the home agent, but there are details that would have > > > to be worked out. > > > > > > Regards, > > > Charlie P. > > > > > > > > > Fredrik Johansson wrote: > > > > > > > Hi, > > > > > > > > the mobile node generates the challenge and send the > request to the home > > > > agent. The home agent will then include the same challenge in the > > > > registration reply, is it up to the implementation of the > > > co-located foreign > > > > agent to remove the challenge before giving it to the mobile > > > client so it is > > > > not misstaken for a new challenge that can be sent in the > > > registration reply > > > > for use in the next registration? > > > > > > > > /Fredrik > > > > > > > > > -----Original Message----- > > > > > From: IP Routing for Wireless/Mobile Hosts (mobile-ip) > > > > > [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of > > > Woo-June Kim > > > > > Sent: den 6 oktober 2000 17:28 > > > > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: [MOBILE-IP] Challenge / Response with co-located FA > > > > > > > > > > > > > > > Fredrik, > > > > > > > > > > The mobile node itself just generates a random number to use as > > > > > the challenge. The response can only be correctly calculated by > > > > > the mobile if it knows the correct key and algorithm. The AAA is > > > > > simply using this fact to check the mobile's identity in a > > > > > round-about manner. The challenge value itself is not something > > > > > that must be generated in some special manner. > > > > > > > > > > cheers > > > > > > > > > > >BlankHi > > > > > > > > > > > >I have a question concerning how Challenge / Response is > > > supposed to work > > > > > >when a mobile node registers using a co-located foreign agent. > > > > > > > > > > > >Since the mobile node does not receive an advertisement with > > > a challenge > > > > > >from a FA it cannot calculate a response to be used in a MN-AAA > > > > > >Authentication extension, i.e., the Home Agent cannot use a > > > > > Radius server to > > > > > >authenticate the MN. > > > > > > > > > > > >Have there been any thoughts in this area, or perhaps a > > > solution in an > > > > > >earlier thread that I've missed? Thankful for any pointers. > > > > > > > > > > > >Regards > > > > > >/Fredrik > > > > > >----------------------------------------- > > > > > >Fredrik Johansson > > > > > > > > > > > >W: +46 (0)8 725 5916 > > > > > >M: +46 (0)70 786 5035 > > > > > >mailto:Fredrik.Johansson@ipunplugged.com > > > > > >http://www.ipunplugged.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 12:59: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 MAA09263 for ; Fri, 13 Oct 2000 12:59:58 -0400 (EDT) Received: from standards (47.234.32.16:1303) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3B36@standards.nortelnetworks.com>; Fri, 13 Oct 2000 12:42:57 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10916 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 12:42:56 -0400 Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3B24@standards.nortelnetworks.com>; Fri, 13 Oct 2000 12:32:56 -0400 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA09305 for ; Fri, 13 Oct 2000 08:43:02 -0700 (MST)] Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA14274 for ; Fri, 13 Oct 2000 08:43:02 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r1.mot.com with ESMTP for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 08:42:43 -0700 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id RAA19630 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM.DELIVER; Fri, 13 Oct 2000 17:42:40 +0200 (METDST) Received: from scooter.crm.mot.com (petrescu@riri.crm.mot.com [140.101.173.128]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id RAA19537; Fri, 13 Oct 2000 17:42:38 +0200 (METDST) References: <001101c033ec$f1e096a0$a2388680@kwangwoon.ac.kr> <002c01c0350f$c6b4e7a0$a2388680@kwangwoon.ac.kr> Lines: 24 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: Date: Fri, 13 Oct 2000 17:42:37 +0200 Reply-To: Alexandru Petrescu Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Alexandru Petrescu Subject: Re: [MOBILE-IP] MIPv6 node location detection X-cc: ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: SungJin Lee's message of "Fri, 13 Oct 2000 21:19:03 +0900" SungJin Lee writes: > What is the difference between two advertisement below ? > - Renumbered home link router advertisement > - Router advertisement in a foreign link I'm sharing your surprise there's no written differentiation. It is so striking that I imagine the authors have already thought of it and left it as an exercise :-) Let's say the MN wrongly considers the newly received RA as a movement, when in fact it was renumbering at home. It would first configure a CoA and default route, then try a BU to his HA. Now two things can happen here: (1) either the HA is not yet renumbered, so it will send a Binding Ack or (2) it has been renumbered and is no longer reachable. MN will use either the received Binding Ack (1) or HA Discovery (2) to find out that the HA's prefix is the same as the initial MN prefix (1) or as the CoA (2). Surprise, you're at home, so BU again, this time with zeroed lifetime to remove wrong cache entry. Thus, renumbering took place and not visiting. I think this would not work if home net and visited net both renumber at the same time and take each other's prefixes. Alex From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 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 NAA09445 for ; Fri, 13 Oct 2000 13:14:22 -0400 (EDT) Received: from standards (47.234.32.16:1303) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3BA0@standards.nortelnetworks.com>; Fri, 13 Oct 2000 12:57:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11021 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 12:57:15 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3B75@standards.nortelnetworks.com>; Fri, 13 Oct 2000 12:47:15 -0400 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA21977 for ; Fri, 13 Oct 2000 11:02:08 -0600 (MDT) 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 KAA25798; Fri, 13 Oct 2000 10:02:06 -0700 (PDT) Received: from sunray-mpke (sunray-mpke [129.146.6.32]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA24049; Fri, 13 Oct 2000 10:02:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 0iwPc8g2781oebJfSOxuBA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Message-ID: <200010131702.KAA24049@nasnfs.eng.sun.com> Date: Fri, 13 Oct 2000 10:02:05 -0700 Reply-To: Vipul Gupta Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Vipul Gupta Subject: Re: [MOBILE-IP] Mobile IP Routing Implementation Issue X-To: gavin.button@panasonic-pmdc.co.uk To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Gavin, When the mobile node is away from its home network, you need to remove the routing table entry for the home network (100.100.100.0). The only route entries you should have are: - an entry that says the FA (default router) is directly reachable from the MN's network interface - traffic for all hosts must be directed to the default router (FA). This way, the MN's IP forwarding code will not try to ARP for 100.100.100.207. Instead, the packet will be sent to the FA. You don't mention what operating system you are using but at least Solaris and Linux allow routing tables to be set as above. vipul > Hi All, > > I am researching and implementing MobileIP as defined in RFC2002, October > 1996 and have a question. > > My configuration within a private network is as follows: > Mobile Host: IP address 100.100.101.239 > Home Agent: IP address 100.100.101.233 > Foreign Agent: IP Address 10.0.0.2 > (all subnet masks are 255.255.255.0) > > The Mobile Host visits the Foreign Agent network and registers the Care of > Address (10.0.0.2) with the Home Agent. Once registration has completed I > ping the Mobile Host from a machine on its Home Network (100.100.100.207). > The ping request reaches the Mobile Host succesfully, at which point the > TCP/IP stack attempts a broadcast ARP Request to determine the MAC address > of 100.100.101.207, which it believes to be on the same network, this fails > so the ping reply is never generated. > > The section in RFC 2002 on Mobile Host Datagram Routing (4.2.1) states that > a default router should be selected for the foreign network. If I do this > and set the deafult router to be 10.0.0.1 (router between the two networks) > then it still does generates an ARP request for 100.100.101.207. I believe > this is because the TCP/IP stack doesnt recognise the router, 10.0.0.1, as > being on the same network as its IP Address, 100.100.101.239, so does not > consider it for sending the ping reply to. > > Can anyone explain what I might be doing wrong? > > Thanks in Advance, > > Gavin Button From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 13:51:28 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 NAA09852 for ; Fri, 13 Oct 2000 13:51:27 -0400 (EDT) Received: from standards (47.234.32.16:1303) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3C1D@standards.nortelnetworks.com>; Fri, 13 Oct 2000 13:34:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11223 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 13:34:25 -0400 Received: from sierra.seas.upenn.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3C11@standards.nortelnetworks.com>; Fri, 13 Oct 2000 13:24:24 -0400 Received: from eunyoung (NIC-23-115.RESNET.UPENN.EDU [130.91.23.115]) by sierra.seas.upenn.edu (8.9.3/8.9.3) with SMTP id NAA22961 for ; Fri, 13 Oct 2000 13:39:19 -0400 (EDT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C0351B.50CD6100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <001401c0353c$d83f4970$73175b82@phone.com> Date: Fri, 13 Oct 2000 13:41:40 -0400 Reply-To: Eunyoung Kim Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Eunyoung Kim Subject: [MOBILE-IP] Unsubscribe To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C0351B.50CD6100 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 dW5zdWJzY3JpYmUgDQpla2ltM0BzZWFzLnVwZW5uLmVkdQ0KDQpUaGFua3MNCg== ------=_NextPart_000_0011_01C0351B.50CD6100 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjIzMTQuMTAwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPnVuc3Vic2Ny aWJlIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxBIA0KaHJlZj0ibWFpbHRvOmVr aW0zQHNlYXMudXBlbm4uZWR1Ij5la2ltM0BzZWFzLnVwZW5uLmVkdTwvQT48L0ZPTlQ+PC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+VGhhbmtzPC9GT05UPjwvRElW PjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0011_01C0351B.50CD6100-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 23: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 XAA17066 for ; Fri, 13 Oct 2000 23:43:37 -0400 (EDT) Received: from standards (47.234.32.16:3044) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3E88@standards.nortelnetworks.com>; Fri, 13 Oct 2000 23:26:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12034 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 23:26:45 -0400 Received: from sj-msg-core-2.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3E86@standards.nortelnetworks.com>; Fri, 13 Oct 2000 23:26:44 -0400 Received: from p7020-img-nt.cisco.com (sj-dial-3-15.cisco.com [171.68.180.16]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id UAA13905; Fri, 13 Oct 2000 20:41:37 -0700 (PDT) X-Sender: fred@flipper X-Mailer: QUALCOMM Windows Eudora Version 5.0 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.0.0.25.2.20001013191004.02a845a0@flipper> Date: Fri, 13 Oct 2000 19:22:49 -0600 Reply-To: Fred Baker Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fred Baker Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: SungJin Lee X-cc: ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <001101c033ec$f1e096a0$a2388680@kwangwoon.ac.kr> I am not the most knowledgeable on the subject, and my betters may correct me. But I would think this has to be answered in the exchange with the Home Agent. First, the Mobile Node has a number of limitations on its knowledge. It doesn't know its own prefix beyond what it received in a router advertisement, for example - if the router advertisement has changed prefix, that may well mean that the device has changed subnet within its home domain and should just use that address, or as you suggest, it may mean that somebody is renumbering the network. Since it doesn't know the site prefix, it cannot distinguish between the home domain (which is larger than the prefix for a particular subnet) and a foreign domain. It also has a responsibility. It must keep the Home Agent apprised both of its own current address and its current care-of address. So if its address changes, or if a new address is added to its list on some interface, it is going to have to advise the Home Agent of that. It is from the Home Agent's response that it will determine what's happening. If the Home Agent expresses the opinion that it needs to use the COA, it probably does, and if the Home Agent thinks its address is just fine... Now, I haven't read the latest specifications to tell you how the Home Agent expresses that. But I think it is in that context that the information is going to have to be derived and communicated. At 10:37 AM 10/12/00 +0900, SungJin Lee wrote: >I got confisued while i was reading MIPv6 standards and >have a couple of question with cases like following. The >It is assumed that the MIPv6 node use stateless autoconfiguration. >Let me know if I lost some in MIPv6 and IPv6 RFC. > >Q.1 A MIPv6 node moved to foreign link. The MIPv6 node restarts > the system there and receives router advertisements with > foreign network prefix. > > How do the MIPv6 node detect if it is located in foreign link? > isn't it could be normal autoconfiguration as in the home llink? > >Q.2 A MIPv6 node located in it's home link. The node got an IP address > with stateless autoconfiguration. At a time the router changed the > home link > prefix and multicast the router advertisement with new prefix. > After the home link prefix ifetime expired or before the life time > expired, it received router advertisement with new prefix. > > Why doesn't the IPv6 node think it's located in foreign link when it > received? isn't it possible the IPv6 node to think it's moved to a > foreign > link and start MIPv6 process? From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 23:56: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 XAA17220 for ; Fri, 13 Oct 2000 23:56:16 -0400 (EDT) Received: from standards (47.234.32.16:3044) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3ED6@standards.nortelnetworks.com>; Fri, 13 Oct 2000 23:39:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12133 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 23:39:34 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:56366) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3ED4@standards.nortelnetworks.com>; Fri, 13 Oct 2000 23:39:33 -0400 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 NAA02137 for ; Sat, 14 Oct 2000 13:51:39 +1000 (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 OAA24022 for ; Sat, 14 Oct 2000 14:53:59 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id <4XFQQCJT>; Sat, 14 Oct 2000 14:54:08 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613C79@eaubrnt018.epa.ericsson.se> Date: Sat, 14 Oct 2000 14:54:06 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] MIPv6 node location detection To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Fred > I am not the most knowledgeable on the subject, and my betters may correct > me. But I would think this has to be answered in the exchange with the > Home > Agent. > > First, the Mobile Node has a number of limitations on its knowledge. It > doesn't know its own prefix beyond what it received in a router > advertisement, for example - if the router advertisement has changed > prefix, that may well mean that the device has changed subnet within its > home domain and should just use that address, or as you suggest, it may > mean that somebody is renumbering the network. Since it doesn't know the > site prefix, it cannot distinguish between the home domain (which is > larger > than the prefix for a particular subnet) and a foreign domain. > > It also has a responsibility. It must keep the Home Agent apprised both of > its own current address and its current care-of address. So if its address > changes, or if a new address is added to its list on some interface, it is > going to have to advise the Home Agent of that. > > It is from the Home Agent's response that it will determine what's > happening. If the Home Agent expresses the opinion that it needs to use > the > COA, it probably does, and if the Home Agent thinks its address is just > fine... > > Now, I haven't read the latest specifications to tell you how the Home > Agent expresses that. But I think it is in that context that the > information is going to have to be derived and communicated. > => Well according to my memory there is no such expression from the HA. Of course if the MN receives the new router advertisement from the HA (router on the link), then it will know that the default router is still the same and that there is no need to move. But that is not a fault proof solution because the link-local address may be duplicated between links. Another way of looking at it is that the "new" Ruter advertisement should inform hosts that this subnet is "being renumbered". I think this is a clean option. I don't think this should be a MIP issue. MIPv6 solves the problem when the MN is away from home, which is when MIPv6 is espected to solve it. I would suggest that this is a ND-MIP interaction issue. Hesham > At 10:37 AM 10/12/00 +0900, SungJin Lee wrote: > >I got confisued while i was reading MIPv6 standards and > >have a couple of question with cases like following. The > >It is assumed that the MIPv6 node use stateless autoconfiguration. > >Let me know if I lost some in MIPv6 and IPv6 RFC. > > > >Q.1 A MIPv6 node moved to foreign link. The MIPv6 node restarts > > the system there and receives router advertisements with > > foreign network prefix. > > > > How do the MIPv6 node detect if it is located in foreign link? > > isn't it could be normal autoconfiguration as in the home llink? > > > >Q.2 A MIPv6 node located in it's home link. The node got an IP address > > with stateless autoconfiguration. At a time the router changed > the > > home link > > prefix and multicast the router advertisement with new prefix. > > After the home link prefix ifetime expired or before the life > time > > expired, it received router advertisement with new prefix. > > > > Why doesn't the IPv6 node think it's located in foreign link when > it > > received? isn't it possible the IPv6 node to think it's moved to > a > > foreign > > link and start MIPv6 process? From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Oct 14 04:43: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 EAA01464 for ; Sat, 14 Oct 2000 04:43:01 -0400 (EDT) Received: from standards (47.234.32.16:4966) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4001@standards.nortelnetworks.com>; Sat, 14 Oct 2000 4:26:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12539 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 14 Oct 2000 04:26:09 -0400 Received: from tml-gw.tml.hut.fi (tml.hut.fi) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3FFF@standards.nortelnetworks.com>; Sat, 14 Oct 2000 4:16:08 -0400 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id LAA04344 for ; Sat, 14 Oct 2000 11:31:04 +0300 Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma004337; Sat, 14 Oct 00 11:30:39 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.11.0/8.11.0) with ESMTP id e9E8Uc027237; Sat, 14 Oct 2000 11:30:39 +0300 (EEST) Received: from localhost (lpetande@localhost) by morphine.tml.hut.fi (8.9.2/8.7.1) with ESMTP id LAA28099; Sat, 14 Oct 2000 11:30:22 +0300 (EET DST) X-Authentication-Warning: morphine.tml.hut.fi: lpetande owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Sat, 14 Oct 2000 11:30:22 +0300 Reply-To: Lars Henrik Petander Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Lars Henrik Petander Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: "John F. Leser" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: On Fri, 13 Oct 2000, John F. Leser wrote: > On Sat, 14 Oct 2000, Hesham Soliman (EPA) wrote: > > > Reading through section 10.4 of the MIPv6 draft (version 12), I get the > impression that: > > 1. Movement detection is not a simple problem to solve. The draft > doesn't really specifiy what method should be used. > > 2. Seeing an adverisement from a router with a different prefix is not a > good way to detect movement. That depends whether you are keeping a list of the known routers. If you have a list of all known routers and you hear an advertisement from a new router, which is not on the list, then you have probably moved. This gives you the possibility of making a handoff before losing contact with your current router. Of course the list needs to be purged of routers that have been unreachable for some time. This scheme works well if the user moves linearly, but requires router unreachability detection in other cases. > The preferred movement detection method > seems to be loss of reachability of the MN's default router, which is > noticed through neighbor unreachability detection and/or use of the > router advertisement interval option. Neighbour unreachbility detection is somewhat slow due to the default timer values. Also frequent sending of RAs has some downsides, e.g., heavy processing and bandwidth costs. Since the handoff takes place only after losing the default router, some packets may be lost. Based on my experiences developing the movement detection part of the MIPL implementation, a combination of eager cell switching that is moderated by the list of known routers combined with router unreachbility detection based on the router interval option works well in most cases. Henrik Petander > > > ------------------------------------------------------------------- > 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 Sat Oct 14 10:38: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 KAA03554 for ; Sat, 14 Oct 2000 10:38:38 -0400 (EDT) Received: from standards (47.234.32.16:1453) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4105@standards.nortelnetworks.com>; Sat, 14 Oct 2000 10:21:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12882 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 14 Oct 2000 10:21:28 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA40F7@standards.nortelnetworks.com>; Sat, 14 Oct 2000 10:11:19 -0400 Received: from ns.choongang.co.kr (IDENT:root@[211.175.183.250]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id JAA21955 for ; Sat, 14 Oct 2000 09:26:15 -0500 (CDT) Received: from 63.36.97.65 (1Cust65.tnt4.chi2.da.uu.net [63.36.97.65]) by ns.choongang.co.kr (8.9.3/8.8.7) with SMTP id XAA18592; Sat, 14 Oct 2000 23:25:10 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <00004f137479$0000295e$00005698@> Date: Sat, 14 Oct 2000 10:26:50 -0400 Reply-To: nopaycablea10@webmail.jippii.fi Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: nopaycablea10@webmail.jippii.fi Subject: [MOBILE-IP] Get a FREE $1000 Satellite T.V. System! X-To: getfreesatellitea@rdsnet.ro To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit FREE Satellite T.V. System and FREE Installation For a limited time we'll give you this top of the line Digital Satellite System for FREE! We'll even include Free installation. Enjoy over 500 Channels of crystal clear digital picture and cd stereo sound on your FREE Satellite TV System. Why pay over $900 retail for these items, when we're giving you this satellite package for free. Call 888-514-6881 to be Guaranteed Your FREE Satellite Today This innovative 20" satellite includes a stereo receiver and an infrared remote. With this FREE offer you will have both Interactive Television Capability and an On Screen Program Guide. This limited time FREE offer is much less than the monthly cost of cable tv. All you have to do is call us to arrange delivery. If you call today, we'll throw in a second receiver for your second T.V. free. Call 888-514-6881 to Begin Surfing through 500 Channels Today! To be removed send email to datyups@yahoo.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Oct 14 17:59: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 RAA05694 for ; Sat, 14 Oct 2000 17:59:04 -0400 (EDT) Received: from standards (47.234.32.16:1997) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA42A2@standards.nortelnetworks.com>; Sat, 14 Oct 2000 17:42:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13478 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 14 Oct 2000 17:42:05 -0400 Received: from bkmoh.hu (excalibur.bkmoh.hu) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA429E@standards.nortelnetworks.com>; Sat, 14 Oct 2000 17:32:04 -0400 Received: from doddjio (1Cust102.tnt2.providence.ri.da.uu.net [63.21.182.102]) by bkmoh.hu (8.8.8/8.8.8) with ESMTP id VAA24322; Sat, 14 Oct 2000 21:49:20 +0200 X-Mailer: Microsoft Outlook Express 4..72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <200010141949.VAA24322@bkmoh.hu> Date: Sat, 14 Oct 2000 16:08:13 -0500 Reply-To: Rodney Barron Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Rodney Barron Subject: [MOBILE-IP] Golden Opp. # AF2 X-To: open29e@bkmoh.hu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA05694 *Earn $2000 - $5000 weekly-starting within 1-4 weeks *78% Profit Paid Daily *No Selling *No Risk Guarantee *Work from home, No overhead, or employees. *High Tech Training & Support *Not MLM, 100x more profitable *Multibillion Dollar Travel Industry The most incredible part of our business is that ALL MY CLIENTS CALL ME! DO YOU QUALIFY FOR OUR MENTOR PROGRAM? ACCEPTING ONLY 12 NEW ASSOCIATES This is not a hobby! Serious Inquires Only!! Please reply with the following information NAME: EMAIL ADDRESS: PHONE: (Required) BEST TIME TO CALL: TO: mailto:mxtk@cmpmail.com?subject=more_info //////////////////////////////////////////////////// Please remove at: mailto:bb28b@usa.net?subject=remove //////////////////////////////////////////////////// From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Oct 14 18:32: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 SAA05837 for ; Sat, 14 Oct 2000 18:32:48 -0400 (EDT) Received: from standards (47.234.32.16:4204) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4304@standards.nortelnetworks.com>; Sat, 14 Oct 2000 18:16:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13609 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 14 Oct 2000 18:16:00 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4302@standards.nortelnetworks.com>; Sat, 14 Oct 2000 18:05:59 -0400 Received: from mail.interpia98.net ([210.124.122.24]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id RAA24211 for ; Sat, 14 Oct 2000 17:20:55 -0500 (CDT) Received: from sdn-ar-001tnknoxP016.dialsprint.net_[206.133.83.24] ([206.133.83.24]) by mail.interpia98.net (8.9.3/8.9.3) with SMTP id GAA29303; Sun, 15 Oct 2000 06:26:42 +0900 Received: from 206.133.83.24 by sdn-ar-001tnknoxP016.dialsprint.net with ESMTP; Sat, 14 Oct 2000 18:16:02 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <000001a1609b$00002848$00003d9e@206.133.83.24> Date: Sat, 14 Oct 2000 18:15:52 -0400 Reply-To: chocobo84@EARTHLINK.NET Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: chocobo84@EARTHLINK.NET Subject: [MOBILE-IP] Get Viagra Online Now... 15774 X-To: Undisclosed.Recipients@mail.interpia98.net To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: quoted-printable = Get VIAGRA



the breakthrough medication for impotence

delivered to your mailbox...



..without leaving your computer.



In less than 5 minutes you can complete the on-line consultation and in
many cases have the medication in 24 hours.



From our website to your mailbox.

On-line consultation for treatment of compromised sexual function.



Convenient...affordable....confidential.

We ship VIAGRA worldwide at US prices.



To Order Visit:http://www.webstorealley.com/viagra.cfm?affiliateid=3DDD104= 25







Under Bill 1618 TITLE III passed by the 105th U.S. Congress

this letter can not be considered spam as long as we include:

Contact information & a Remove Link.

TO REMOVE CLICK ON remove@webstorealley.com









































 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Oct 15 04:57: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 EAA07114 for ; Sun, 15 Oct 2000 04:57:55 -0400 (EDT) Received: from standards (47.234.32.16:1991) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4465@standards.nortelnetworks.com>; 15 Oct 2000 4:40:51 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14093 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 15 Oct 2000 04:40:51 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4461@standards.nortelnetworks.com>; 15 Oct 2000 4:30:50 -0400 Received: from mail.controlled-demolition.co.uk (mail.controlled-demolition.co.uk [195.92.182.18]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id DAA27267; Sun, 15 Oct 2000 03:45:47 -0500 (CDT) Received: from 63.38.44.20 [63.38.44.20] by mail.controlled-demolition.co.uk (SMTPD32-5.01) id AFA5E62301F8; Sun, 15 Oct 2000 07:33:09 +0100 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <000057c56e37$0000481d$0000399c@> Date: Sat, 14 Oct 2000 23:32:05 -0700 Reply-To: jmyers0383@DNAI.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: jmyers0383@DNAI.COM Subject: [MOBILE-IP] Get Viagra Now! 14748 X-To: Undisclosed.Recipients@hosaka.smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: quoted-printable Viagra
  Get VIAGRA the breakthrough medication for impotence
  delivered to your mailbox...

  ...without leaving your computer.

  In less than 5 minutes you can complete the on-line consultation   and in many cases have the medication in 24 hours.

  From our w= ebform to your mailbox.
  On-line consultation for treatment of compromised sexual function.

  Convenient...affordable....confidential.
  We ship VIAGRA worldwide at US prices.

  To Order: PLEASE CLICK HERE





  If you received this in error or would like to be
  removed from our list, REMOVE HERE From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Oct 15 20:41: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 UAA11584 for ; Sun, 15 Oct 2000 20:41:22 -0400 (EDT) Received: from standards (47.234.32.16:3176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4614@standards.nortelnetworks.com>; 15 Oct 2000 20:24:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14699 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 15 Oct 2000 20:24:18 -0400 Received: from mail2.microsoft.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4612@standards.nortelnetworks.com>; 15 Oct 2000 20:14:17 -0400 Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 15 Oct 2000 17:28:52 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id <45JL6ZZT>; Sun, 15 Oct 2000 17:28:51 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Message-ID: Date: Sun, 15 Oct 2000 17:28:44 -0700 Reply-To: Brian Zill Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Brian Zill Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: "Hesham Soliman (EPA)" , ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Another way of looking at it is that the "new" > > Ruter advertisement should inform hosts that > > this subnet is "being renumbered". I think > > this is a clean option. I don't think this > > should be a MIP issue. MIPv6 solves the problem > > when the MN is away from home, which is when > > MIPv6 is espected to solve it. I would suggest > > that this is a ND-MIP interaction issue. I don't think this is a general enough solution. In the common case, an administrator would renumber by adding the new prefix and marking the old prefix to time-out. A mobile node that returns home during the time-out delta could probably surmise that a renumbering was going on without needing an extra bit in the router advertisement. Yes, the extra bit could serve to aid those mobile nodes that don't come home until after the old prefix has expired, but how long does the router continue to advertise the "being renumbered" bit? At some point the administrator has to claim that the "being renumbered" state has finished, confusing any mobile nodes that don't return home until after that. And if some administrators never get around to turning the bit off, you'll have some networks in a state of perpetual renumberment. I think there's a better solution. Have mobile nodes attempt to treat every home agent they encounter as their home agent. A mobile node should only be able to successfully do so if the home agent actually is its home agent. Note that there has to be some sort of security authorization between the mobile node and the home agent or bad people visiting your link could steal one of your addresses (such authorization is required for the mobile node to securely update the home agent as to what its care-of-address is, so the authorization capability must exist). In other words, if you pass security, you're at home (or one of your homes, at any rate). Now the MIPv6 draft is a little weak regarding how this authorization should be done, but I think that's a problem for the mobile ip working group. --Brian From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 00:03: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 AAA14856 for ; Mon, 16 Oct 2000 00:03:27 -0400 (EDT) Received: from standards (47.234.32.16:2436) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4696@standards.nortelnetworks.com>; 15 Oct 2000 23:46:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14861 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 15 Oct 2000 23:46:23 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:51687) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4694@standards.nortelnetworks.com>; 15 Oct 2000 23:46:21 -0400 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 NAA22817; Mon, 16 Oct 2000 13:58:28 +1000 (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 PAA22491; Mon, 16 Oct 2000 15:00:49 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id <4XFQRNWL>; Mon, 16 Oct 2000 15:00:59 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613C7C@eaubrnt018.epa.ericsson.se> Date: Mon, 16 Oct 2000 15:00:48 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: Brian Zill , ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > > Another way of looking at it is that the "new" > > > Ruter advertisement should inform hosts that > > > this subnet is "being renumbered". I think > > > this is a clean option. I don't think this > > > should be a MIP issue. MIPv6 solves the problem > > > when the MN is away from home, which is when > > > MIPv6 is espected to solve it. I would suggest > > > that this is a ND-MIP interaction issue. > > I don't think this is a general enough solution. In the common case, an > administrator would renumber by adding the new prefix and marking the old > prefix to time-out. A mobile node that returns home during the time-out > delta could probably surmise that a renumbering was going on without > needing > an extra bit in the router advertisement. Yes, the extra bit could serve > to > aid those mobile nodes that don't come home until after the old prefix has > expired, but how long does the router continue to advertise the "being > renumbered" bit? > => You can do it for the same duration that you advertise dual prefixes for or more. There are no hard rules for how long that should be and I think that's a good thing. I would argue that having a flag is better than simply just advertising two prefixes at the same time. If you have a flag then at least you're encouraging the MN's (or just any IPv6 node) to use the new prefix in establishing its new connection. On the other hand, advertising two prefixes may not necessarily mean that you are renumbering. Even if one of them has a shorter lifetime. > At some point the administrator has to claim that the > "being renumbered" state has finished, confusing any mobile nodes that > don't > return home until after that. And if some administrators never get around > to turning the bit off, you'll have some networks in a state of perpetual > renumberment. > => Well, the way of turning the flag off can be automated and set when you turn it on. I think that would depend on the implementation. As to the confusion if the MN returns after the flag is turned off, I think the confusion already exists, that's why we're having this discussion. Adding the flag will make it possible to reduce the confusion by keeping it on for a bit longer. When I mentioned a "being renumbered" flag I didn't mean that it MUST mean that. You could think of a flag that says "new prefix" and be included in the new prefix option. It certainly should be interpreted in a way that doesn't confuse hosts and make them think they're in a transient state. I'm not saying this is the best way, but it is certainly a stright forward solution that seems quite simple. > I think there's a better solution. Have mobile nodes attempt to treat > every > home agent they encounter as their home agent. A mobile node should only > be > able to successfully do so if the home agent actually is its home agent. > => I'm not quite sure if I understand this correctly. The MN will have a fixed home address with a certain prefix. If it asumes that it has a new Home address every time it hears an RA with the H flag set (for HA), that's ok but that doesn't solve the mobility problem for other Home addresses. It still needs to update the original "home" HA. The HA is only updated when the MN is in foreign subnet. What you're saing (if I understood it correctly) means the MN will have a new Home Address every time it moves to a new subnet. Again that's fine but it doesn't help the fixed home address and all the connections using it. > Note that there has to be some sort of security authorization between the > mobile node and the home agent or bad people visiting your link could > steal > one of your addresses (such authorization is required for the mobile node > to > securely update the home agent as to what its care-of-address is, so the > authorization capability must exist). In other words, if you pass > security, > you're at home (or one of your homes, at any rate). > => That authorisation only happens when you're in a foreign subnet. > Now the MIPv6 draft is > a little weak regarding how this authorization should be done, but I think > that's a problem for the mobile ip working group. > => I disagree here. MIPv6 BUs are secured using AH and that's mandatory. How a security asociation is established is not a MIP problem. It can be manually configured or dynamically using IKE. Hesham From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 04:06: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 EAA00462 for ; Mon, 16 Oct 2000 04:06:01 -0400 (EDT) Received: from standards (47.234.32.16:4302) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4866@standards.nortelnetworks.com>; Mon, 16 Oct 2000 3:48:57 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15501 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 03:48:56 -0400 Received: from finch-post-12.mail.demon.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4864@standards.nortelnetworks.com>; Mon, 16 Oct 2000 3:48:56 -0400 Received: from panasonic-pmdc.demon.co.uk ([194.222.202.84] helo=panasonic-pmdc) by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1) id 13l5FU-000Ogq-0C; Mon, 16 Oct 2000 08:03:57 +0000 Received: from 100.100.101.233 by panasonic-pmdc ([100.100.101.232] running VPOP3) with SMTP; Mon, 16 Oct 2000 09:08:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-Server: VPOP3 V1.4.0b - Registered to: Panasonic PMDC Message-ID: <000a01c03747$025451e0$e9656464@pc1233> Date: Mon, 16 Oct 2000 08:59:27 +0100 Reply-To: gavin.button@panasonic-pmdc.co.uk Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gavin Button Subject: Re: [MOBILE-IP] Mobile IP Routing Implementation Issue X-cc: Vipul Gupta To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200010131702.KAA24049@nasnfs.eng.sun.com> Content-Transfer-Encoding: 7bit Vipul, Thanks for your comments. I am developing under Windows 2000 and there doesn't seem to be any obvious way of manipulating the router tables from the device driver level. I was considering answering the ARP message myself with the address of the default router. With regards to your comments about what the router tables should be set to. - In the network configuration I have set up, the FA is not actually the default router for the network, does it have to be? - Windows 2000 doesn't seem to allow you to set up routes which are incorrect, i.e. Sending packets to a router with an IP Address that is not on the same network. Regards, Gavin Button -----Original Message----- From: IP Routing for Wireless/Mobile Hosts (mobile-ip) [mailto:MOBILE-IP@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Vipul Gupta Sent: 13 October 2000 18:02 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] Mobile IP Routing Implementation Issue Gavin, When the mobile node is away from its home network, you need to remove the routing table entry for the home network (100.100.100.0). The only route entries you should have are: - an entry that says the FA (default router) is directly reachable from the MN's network interface - traffic for all hosts must be directed to the default router (FA). This way, the MN's IP forwarding code will not try to ARP for 100.100.100.207. Instead, the packet will be sent to the FA. You don't mention what operating system you are using but at least Solaris and Linux allow routing tables to be set as above. vipul > Hi All, > > I am researching and implementing MobileIP as defined in RFC2002, October > 1996 and have a question. > > My configuration within a private network is as follows: > Mobile Host: IP address 100.100.101.239 > Home Agent: IP address 100.100.101.233 > Foreign Agent: IP Address 10.0.0.2 > (all subnet masks are 255.255.255.0) > > The Mobile Host visits the Foreign Agent network and registers the Care of > Address (10.0.0.2) with the Home Agent. Once registration has completed I > ping the Mobile Host from a machine on its Home Network (100.100.100.207). > The ping request reaches the Mobile Host succesfully, at which point the > TCP/IP stack attempts a broadcast ARP Request to determine the MAC address > of 100.100.101.207, which it believes to be on the same network, this fails > so the ping reply is never generated. > > The section in RFC 2002 on Mobile Host Datagram Routing (4.2.1) states that > a default router should be selected for the foreign network. If I do this > and set the deafult router to be 10.0.0.1 (router between the two networks) > then it still does generates an ARP request for 100.100.101.207. I believe > this is because the TCP/IP stack doesnt recognise the router, 10.0.0.1, as > being on the same network as its IP Address, 100.100.101.239, so does not > consider it for sending the ping reply to. > > Can anyone explain what I might be doing wrong? > > Thanks in Advance, > > Gavin Button From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 08: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 IAA03726 for ; Mon, 16 Oct 2000 08:31:40 -0400 (EDT) Received: from standards (47.234.32.16:1520) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4A35@standards.nortelnetworks.com>; Mon, 16 Oct 2000 8:14:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16110 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 08:14:13 -0400 Received: from sj-msg-core-2.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4A33@standards.nortelnetworks.com>; Mon, 16 Oct 2000 8:14:12 -0400 Received: from p7020-img-nt.cisco.com ([64.104.42.77]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id FAA22248; Mon, 16 Oct 2000 05:28:48 -0700 (PDT) X-Sender: fred@flipper X-Mailer: QUALCOMM Windows Eudora Version 5.0 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.0.0.25.2.20001015183014.0283c5c0@flipper> Date: Sun, 15 Oct 2000 18:44:27 -0700 Reply-To: Fred Baker Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fred Baker Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: SungJin Lee X-cc: ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <001101c033ec$f1e096a0$a2388680@kwangwoon.ac.kr> I came up with the answer to your question. It takes some work, but it's there. Review draft-ietf-mobileip-ipv6-12.txt One the router advertisements (sections 4.1, 5.6, 5.7, etc), the routers tell you whether they are willing to be a home agent and/or a foreign agent. If no neighboring system is willing to be your home agent but there is a foreign agent, you are roaming. If there is someone willing to be a home agent but you cannot authenticate with him, your previous home agent remains your home agent, and you are roaming. If someone advertises that he will be your home agent and you can authenticate with him, you are at home. The one thing that bothered me as I read this was an implicit assumption, perhaps on my part and perhaps on the author's part, that the device has to somehow come in contact with its home agent as a neighboring device once in a while. I can think of a number of scenarios in which this may not be true - imagine a case where you have a telephone mailed to you on the road because the old one broke. You certainly want to be able to tell the new phone the old phone's information and have it stick. Or imagine a device which is permanently roaming - it never actually is at home. You would want to configure a home agent address somehow. I trust that in these cases the protocol is not required. At 09:37 AM 10/12/00 +0900, SungJin Lee wrote: >I got confisued while i was reading MIPv6 standards and >have a couple of question with cases like following. The >It is assumed that the MIPv6 node use stateless autoconfiguration. >Let me know if i lost some in MIPv6 and IPv6 RFC. > >Q.1 A MIPv6 node moved to foreign link. The MIPv6 node restarts > the system there and receives router advertisements with > foreign network prefix. > > How do the MIPv6 node detect if it is located in foreign link ? > isn't it could be normal autoconfiguration as in the home llink ? > >Q.2 A MIPv6 node located in it's home link. The node got an IP address > with stateless autoconfiguration. At a time the router changed > the home link > prefix and multicast the router advertisement with new prefix. > After the home link prefix ifetime expired or before the life time > expired, it received router advertisement with new prefix. > > Why doesn't the IPv6 node think it's located in foreign link when it > received ? isn't it possible the IPv6 node to think it's moved to > a foreign > link and start MIPv6 process ? > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 11:01: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 LAA07016 for ; Mon, 16 Oct 2000 11:01:17 -0400 (EDT) Received: from standards (47.234.32.16:1520) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4BD5@standards.nortelnetworks.com>; Mon, 16 Oct 2000 10:44:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16654 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 10:44:20 -0400 Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4BCF@standards.nortelnetworks.com>; Mon, 16 Oct 2000 10:34:19 -0400 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA01821 for ; Mon, 16 Oct 2000 07:49:23 -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 HAA11056 for ; Mon, 16 Oct 2000 07:49:23 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2651.58) id <4Q3R8676>; Mon, 16 Oct 2000 09:48:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Message-ID: Date: Mon, 16 Oct 2000 09:48:16 -0500 Reply-To: Roberts Philip-qa3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Philip-qa3445 Subject: [MOBILE-IP] san diego To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi folks, it's time to start planning for the San Diego meeting. Please send us your requests for slots in the Mobile IP meeting. Let us know the name of the presenter, the name of the I-D, and the amount of time requested. Thanks, Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 11:13: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 LAA07311 for ; Mon, 16 Oct 2000 11:13:50 -0400 (EDT) Received: from standards (47.234.32.16:1520) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4C27@standards.nortelnetworks.com>; Mon, 16 Oct 2000 10:56:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16691 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 10:56:26 -0400 Received: from tml-gw.tml.hut.fi (tml.hut.fi) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4BED@standards.nortelnetworks.com>; Mon, 16 Oct 2000 10:46:25 -0400 Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id SAA25585 for ; Mon, 16 Oct 2000 18:01:25 +0300 Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma025578; Mon, 16 Oct 00 18:01:21 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.11.0/8.11.0) with ESMTP id e9GF1K005335; Mon, 16 Oct 2000 18:01:20 +0300 (EEST) Received: from localhost (lyang@localhost) by morphine.tml.hut.fi (8.9.2/8.7.1) with ESMTP id SAA03743; Mon, 16 Oct 2000 18:01:03 +0300 (EET DST) X-Authentication-Warning: morphine.tml.hut.fi: lyang owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Mon, 16 Oct 2000 18:01:03 +0300 Reply-To: Linfeng Yang Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Linfeng Yang Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: "Hesham Soliman (EPA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A50C613C7C@eaubrnt018.epa.ericsson.se> When I read Section 12 RENUMBERING CONSIDERATION of RFC 2461 "Neighbor Discovery for IPv6", I got a feeling, renumbering should not happen in a sudden. A best practice would be: before new prefix being advertised, the old one will be advertised with progress shorter Lifetime time and with progress shorter interval. At the point old prefix being advertised with 0 Lifetime, new prefix will be advertised, after that point, old prefix will continue be advertised with a Lifetime of 0 for some period of time. So the MN should be well prepared for renumbering, and thus distinguish renumbering with movement detection. In any case MN should avoid unplugged for a period of time longer than its HA expiration time as the same section of RFC suggested. Linfeng From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 12:12: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 MAA09005 for ; Mon, 16 Oct 2000 12:12:34 -0400 (EDT) Received: from standards (47.234.32.16:4884) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4CDE@standards.nortelnetworks.com>; Mon, 16 Oct 2000 11:55:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17002 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 11:55:33 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4CDC@standards.nortelnetworks.com>; Mon, 16 Oct 2000 11:55:32 -0400 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 e9GGASs24163; Mon, 16 Oct 2000 18:10:28 +0200 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 SAA22774; Mon, 16 Oct 2000 18:10:27 +0200 (MET DST) 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 SAA65104; Mon, 16 Oct 2000 18:14:44 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200010161614.SAA65104@givry.rennes.enst-bretagne.fr> Date: Mon, 16 Oct 2000 18:14:44 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] san diego X-To: Roberts Philip-qa3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Mon, 16 Oct 2000 09:48:16 CDT. In your previous mail you wrote: it's time to start planning for the San Diego meeting. Please send us your requests for slots in the Mobile IP meeting. Let us know the name of the presenter, the name of the I-D, and the amount of time requested. => if nobody better qualified would like to do it: name: Francis Dupont subject: Mobile IPv6 ETSI "bake-off" report (http://www.etsi.org/bake-off/) request: as little as possible (proposal: 2 mn, 3 slides) Thanks Francis.Dupont@enst-bretagne.fr PS: as a new draft should be available before San Diego I can reveal (:-) the main result: a successful registration (BU/BA exchange) protected by IPsec between two very different implementations (ie. the core of the current spec was validated). From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 12:55: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 MAA10326 for ; Mon, 16 Oct 2000 12:55:20 -0400 (EDT) Received: from standards (47.234.32.16:4884) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4D6F@standards.nortelnetworks.com>; Mon, 16 Oct 2000 12:38:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17196 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 12:38:24 -0400 Received: from iol.unh.edu (mars.iol.unh.edu) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4D6D@standards.nortelnetworks.com>; Mon, 16 Oct 2000 12:38:23 -0400 Received: from localhost (jfl@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id MAA13981; Mon, 16 Oct 2000 12:55:10 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Mon, 16 Oct 2000 12:55:10 -0400 Reply-To: "John F. Leser" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "John F. Leser" Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: Brian Zill To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: On Sun, 15 Oct 2000, Brian Zill wrote: > > > Another way of looking at it is that the "new" > > > Ruter advertisement should inform hosts that > > > this subnet is "being renumbered". I think > > > this is a clean option. I don't think this > > > should be a MIP issue. MIPv6 solves the problem > > > when the MN is away from home, which is when > > > MIPv6 is espected to solve it. I would suggest > > > that this is a ND-MIP interaction issue. > > I don't think this is a general enough solution. In the common case, an > administrator would renumber by adding the new prefix and marking the old > prefix to time-out. A mobile node that returns home during the time-out > delta could probably surmise that a renumbering was going on without needing > an extra bit in the router advertisement. Yes, the extra bit could serve to > aid those mobile nodes that don't come home until after the old prefix has > expired, but how long does the router continue to advertise the "being > renumbered" bit? At some point the administrator has to claim that the > "being renumbered" state has finished, confusing any mobile nodes that don't > return home until after that. And if some administrators never get around > to turning the bit off, you'll have some networks in a state of perpetual > renumberment. > I agree here - if you're going to keep your network in a "being renumbered" state, why not just continue to advertise the old prefix as on-link, but with 0 valid lifetime. This would make it clear to any node returning to the home network that something has changed. Also, given just a renumbered bit set in the RA, how does a MN tell its renumbered home network from a renumbered foreign network? > I think there's a better solution. Have mobile nodes attempt to treat every > home agent they encounter as their home agent. A mobile node should only be > able to successfully do so if the home agent actually is its home agent. > Note that there has to be some sort of security authorization between the > mobile node and the home agent or bad people visiting your link could steal > one of your addresses (such authorization is required for the mobile node to > securely update the home agent as to what its care-of-address is, so the > authorization capability must exist). In other words, if you pass security, > you're at home (or one of your homes, at any rate). Now the MIPv6 draft is > a little weak regarding how this authorization should be done, but I think > that's a problem for the mobile ip working group. > > --Brian > This has me a bit confused - I thought the role of IPsec was just to verify that the Binding Update's source could be authenticated as the true owner of the home address, and that allowing the node to make a home registration was based on 1. whether the HA considers the home address on-link and 2. additional policy. In a nutshell, I think some MN and HA could have security associations satisfying all of the requirements for mobility, but this does not mean that the HA is providing services for the MN's home network. ------------------------------------------------------------------- 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 Oct 16 13:09: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 NAA10784 for ; Mon, 16 Oct 2000 13:09:53 -0400 (EDT) Received: from standards (47.234.32.16:4884) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4E0A@standards.nortelnetworks.com>; Mon, 16 Oct 2000 12:52:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17272 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 12:52:48 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4DA9@standards.nortelnetworks.com>; Mon, 16 Oct 2000 12:42:47 -0400 Received: from mailsorter-105-2.iap.bryant.webtv.net (mailsorter-105-2.iap.bryant.webtv.net [209.240.198.118]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id LAA06369 for ; Mon, 16 Oct 2000 11:57:51 -0500 (CDT) Received: from storefull-254.iap.bryant.webtv.net (storefull-254.iap.bryant.webtv.net [209.240.199.132]) by mailsorter-105-2.iap.bryant.webtv.net (WebTV_Postfix) with ESMTP id 4900C2D117 for ; Mon, 16 Oct 2000 09:57:45 -0700 (PDT) Received: (from production@localhost) by storefull-254.iap.bryant.webtv.net (8.8.8-wtv-e/mt.gso.26Feb98) id JAA03812; Mon, 16 Oct 2000 09:57:45 -0700 (PDT) X-WebTV-Signature: 1 ETAtAhRtNdL+due4mSXWsRkRlPdB8Jr7mQIVALdmFZB517JPGuS/CJr4jN9qhOTy Content-Disposition: Inline Content-Type: Text/Plain; Charset=US-ASCII Content-Transfer-Encoding: 7Bit MIME-Version: 1.0 (WebTV) Message-ID: <20455-39EB3388-648@storefull-254.iap.bryant.webtv.net> Date: Mon, 16 Oct 2000 12:57:44 -0400 Reply-To: Robert Greene Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Robert Greene Subject: [MOBILE-IP] New ID X-To: mobile-ip@hosaka.SmallWorks.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7Bit Please send me a new ID From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 13:18:28 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 NAA11124 for ; Mon, 16 Oct 2000 13:18:27 -0400 (EDT) Received: from standards (47.234.32.16:4884) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4E27@standards.nortelnetworks.com>; Mon, 16 Oct 2000 12:55:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17306 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 12:55:42 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4DC3@standards.nortelnetworks.com>; Mon, 16 Oct 2000 12:45:42 -0400 Received: from mailsorter-105-2.iap.bryant.webtv.net (mailsorter-105-2.iap.bryant.webtv.net [209.240.198.118]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id MAA06405 for ; Mon, 16 Oct 2000 12:00:45 -0500 (CDT) Received: from storefull-254.iap.bryant.webtv.net (storefull-254.iap.bryant.webtv.net [209.240.199.132]) by mailsorter-105-2.iap.bryant.webtv.net (WebTV_Postfix) with ESMTP id 05DFC2D31D for ; Mon, 16 Oct 2000 10:00:45 -0700 (PDT) Received: (from production@localhost) by storefull-254.iap.bryant.webtv.net (8.8.8-wtv-e/mt.gso.26Feb98) id KAA03927; Mon, 16 Oct 2000 10:00:44 -0700 (PDT) X-WebTV-Signature: 1 ETAtAhRCLd14SQI8Y9MmnXxUea8u6Em8ewIVAKdw3MQIC98z4HeNhD08y6KWAGsY Content-Disposition: Inline Content-Type: Text/Plain; Charset=US-ASCII Content-Transfer-Encoding: 7Bit MIME-Version: 1.0 (WebTV) Message-ID: <20456-39EB343C-584@storefull-254.iap.bryant.webtv.net> Date: Mon, 16 Oct 2000 13:00:44 -0400 Reply-To: Robert Greene Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Robert Greene Subject: [MOBILE-IP] Adding to my just sent message. X-To: mobile-ip@hosaka.SmallWorks.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7Bit Please e mail me as to the cost for this new ID and I will arrange it immediately. Please advise From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 16:37: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 QAA15687 for ; Mon, 16 Oct 2000 16:37:26 -0400 (EDT) Received: from standards (47.234.32.16:1088) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4F7B@standards.nortelnetworks.com>; Mon, 16 Oct 2000 16:20:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17881 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 16:20:29 -0400 Received: from sj-msg-core-2.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4F79@standards.nortelnetworks.com>; Mon, 16 Oct 2000 16:20:29 -0400 Received: from p7020-img-nt.cisco.com ([64.104.42.52]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA15408; Mon, 16 Oct 2000 13:31:14 -0700 (PDT) X-Sender: fred@flipper X-Mailer: QUALCOMM Windows Eudora Version 5.0 References: <4B6BC00CD15FD2119E5F0008C7A419A50C613C7C@eaubrnt018.epa.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.0.0.25.2.20001017052327.040a5790@flipper> Date: Tue, 17 Oct 2000 05:26:57 -0700 Reply-To: Fred Baker Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fred Baker Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: Linfeng Yang To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: The issues are a lot greater than that. If you want to read my initial thoughts on a procedure (which are by no means done; this was put up for review by the IPv6 Directorate ad will eventually be published as an ID) you can glance at ftp://ftpeng.cisco.com/fred/iesg/draft-baker-ipng-renumbering-00.html At 06:01 PM 10/16/00 +0300, Linfeng Yang wrote: >When I read Section 12 RENUMBERING CONSIDERATION of RFC 2461 "Neighbor >Discovery for IPv6", I got a feeling, renumbering should not happen in a >sudden. A best practice would be: before new prefix being advertised, the >old one will be advertised with progress shorter Lifetime time and with >progress shorter interval. At the point old prefix being advertised with 0 >Lifetime, new prefix will be advertised, after that point, old prefix will >continue be advertised with a Lifetime of 0 for some period of time. > >So the MN should be well prepared for renumbering, and thus distinguish >renumbering with movement detection. > >In any case MN should avoid unplugged for a period of time longer than its >HA expiration time as the same section of RFC suggested. > >Linfeng From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 18:32: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 SAA17158 for ; Mon, 16 Oct 2000 18:32:33 -0400 (EDT) Received: from standards (47.234.32.16:1078) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA504C@standards.nortelnetworks.com>; Mon, 16 Oct 2000 18:15:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18163 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 18:15:42 -0400 Received: from sj-msg-core-2.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA504A@standards.nortelnetworks.com>; Mon, 16 Oct 2000 18:15:41 -0400 Received: from p7020-img-nt.cisco.com ([64.104.42.52]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA29738; Mon, 16 Oct 2000 15:30:47 -0700 (PDT) X-Sender: fred@flipper X-Mailer: QUALCOMM Windows Eudora Version 5.0 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.0.0.25.2.20001017064711.0397a5f0@flipper> Date: Tue, 17 Oct 2000 06:51:14 -0700 Reply-To: Fred Baker Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fred Baker Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: Brian Zill To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: At 05:28 PM 10/15/00 -0700, Brian Zill wrote: >I think there's a better solution. Have mobile nodes attempt to treat every >home agent they encounter as their home agent. A mobile node should only be >able to successfully do so if the home agent actually is its home agent. There is something to be said for that, apart from policy. I suspect there is actually a mutual authorization thing going on - I may be willing to be your home agent, but you may prefer another, and you may be willing for me to be your home agent, but I think you don't pay your bills. Reality is that we both have to be willing. We can't determine that unless we ask the question. So if we moderate the statement to "have mobile nodes attempt to treat every home agent that they accept by policy as their home agent", then the intersection will be determined by the home agent. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 23:35: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 XAA21364 for ; Mon, 16 Oct 2000 23:35:54 -0400 (EDT) Received: from standards (47.234.32.16:2896) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5164@standards.nortelnetworks.com>; Mon, 16 Oct 2000 23:18:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18516 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 23:18:56 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:45208) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5162@standards.nortelnetworks.com>; Mon, 16 Oct 2000 23:18:54 -0400 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 NAA28085 for ; Tue, 17 Oct 2000 13:31:04 +1000 (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 OAA21410 for ; Tue, 17 Oct 2000 14:33:27 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id <4XFQSF7R>; Tue, 17 Oct 2000 14:33:37 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613C84@eaubrnt018.epa.ericsson.se> Date: Tue, 17 Oct 2000 14:33:35 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: "John F. Leser" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > > > Another way of looking at it is that the "new" > > > > Ruter advertisement should inform hosts that > > > > this subnet is "being renumbered". I think > > > > this is a clean option. I don't think this > > > > should be a MIP issue. MIPv6 solves the problem > > > > when the MN is away from home, which is when > > > > MIPv6 is espected to solve it. I would suggest > > > > that this is a ND-MIP interaction issue. > > > > I don't think this is a general enough solution. In the common case, an > > administrator would renumber by adding the new prefix and marking the > old > > prefix to time-out. A mobile node that returns home during the time-out > > delta could probably surmise that a renumbering was going on without > needing > > an extra bit in the router advertisement. Yes, the extra bit could > serve to > > aid those mobile nodes that don't come home until after the old prefix > has > > expired, but how long does the router continue to advertise the "being > > renumbered" bit? At some point the administrator has to claim that the > > "being renumbered" state has finished, confusing any mobile nodes that > don't > > return home until after that. And if some administrators never get > around > > to turning the bit off, you'll have some networks in a state of > perpetual > > renumberment. > > > I agree here - if you're going to keep your network in a "being > renumbered" state, why not just continue to advertise the old prefix as > on-link, but with 0 valid lifetime. This would make it clear to any node > returning to the home network that something has changed. Also, given > just a renumbered bit set in the RA, how does a MN tell its renumbered > home network from a renumbered foreign network? > => > > I think there's a better solution. Have mobile nodes attempt to treat > every > > home agent they encounter as their home agent. A mobile node should > only be > > able to successfully do so if the home agent actually is its home agent. > > Note that there has to be some sort of security authorization between > the > > mobile node and the home agent or bad people visiting your link could > steal > > one of your addresses (such authorization is required for the mobile > node to > > securely update the home agent as to what its care-of-address is, so the > > authorization capability must exist). In other words, if you pass > security, > > you're at home (or one of your homes, at any rate). Now the MIPv6 draft > is > > a little weak regarding how this authorization should be done, but I > think > > that's a problem for the mobile ip working group. > > > > --Brian > > > This has me a bit confused - I thought the role of IPsec was just to > verify that the Binding Update's source could be authenticated as the true > owner of the home address, and that allowing the node to make a home > registration was based on 1. whether the HA considers the home address > on-link and 2. additional policy. > > In a nutshell, I think some MN and HA could have security associations > satisfying all of the requirements for mobility, but this does not mean > that the HA is providing services for the MN's home network. > > > ------------------------------------------------------------------- > 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 Oct 16 23:45: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 XAA21540 for ; Mon, 16 Oct 2000 23:45:15 -0400 (EDT) Received: from standards (47.234.32.16:2896) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA518D@standards.nortelnetworks.com>; Mon, 16 Oct 2000 23:22:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18568 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 23:22:34 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:45334) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA518B@standards.nortelnetworks.com>; Mon, 16 Oct 2000 23:22:32 -0400 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 NAA28466 for ; Tue, 17 Oct 2000 13:34:43 +1000 (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 OAA21983 for ; Tue, 17 Oct 2000 14:37:07 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id <4XFQSGA5>; Tue, 17 Oct 2000 14:37:17 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613C85@eaubrnt018.epa.ericsson.se> Date: Tue, 17 Oct 2000 14:37:10 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] MIPv6 node location detection To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Sorry about the last mail, a bit eager on the send button :) > > > > Another way of looking at it is that the "new" > > > > Ruter advertisement should inform hosts that > > > > this subnet is "being renumbered". I think > > > > this is a clean option. I don't think this > > > > should be a MIP issue. MIPv6 solves the problem > > > > when the MN is away from home, which is when > > > > MIPv6 is espected to solve it. I would suggest > > > > that this is a ND-MIP interaction issue. > > > > I don't think this is a general enough solution. In the common case, an > > administrator would renumber by adding the new prefix and marking the > old > > prefix to time-out. A mobile node that returns home during the time-out > > delta could probably surmise that a renumbering was going on without > needing > > an extra bit in the router advertisement. Yes, the extra bit could > serve to > > aid those mobile nodes that don't come home until after the old prefix > has > > expired, but how long does the router continue to advertise the "being > > renumbered" bit? At some point the administrator has to claim that the > > "being renumbered" state has finished, confusing any mobile nodes that > don't > > return home until after that. And if some administrators never get > around > > to turning the bit off, you'll have some networks in a state of > perpetual > > renumberment. > > > I agree here - if you're going to keep your network in a "being > renumbered" state, why not just continue to advertise the old prefix as > on-link, but with 0 valid lifetime. This would make it clear to any node > returning to the home network that something has changed. Also, given > just a renumbered bit set in the RA, how does a MN tell its renumbered > home network from a renumbered foreign network? > => That's fine with me too. As long as there is some indication that the network has been renumbered and as long as it is done outside MIPv6 ;) I don't think it's a MIPv6 problem if it is done while you're at home. > > I think there's a better solution. Have mobile nodes attempt to treat > every > > home agent they encounter as their home agent. A mobile node should > only be > > able to successfully do so if the home agent actually is its home agent. > > Note that there has to be some sort of security authorization between > the > > mobile node and the home agent or bad people visiting your link could > steal > > one of your addresses (such authorization is required for the mobile > node to > > securely update the home agent as to what its care-of-address is, so the > > authorization capability must exist). In other words, if you pass > security, > > you're at home (or one of your homes, at any rate). Now the MIPv6 draft > is > > a little weak regarding how this authorization should be done, but I > think > > that's a problem for the mobile ip working group. > > > > --Brian > > > This has me a bit confused - I thought the role of IPsec was just to > verify that the Binding Update's source could be authenticated as the true > owner of the home address, and that allowing the node to make a home > registration was based on 1. whether the HA considers the home address > on-link and 2. additional policy. > > In a nutshell, I think some MN and HA could have security associations > satisfying all of the requirements for mobility, but this does not mean > that the HA is providing services for the MN's home network. > => The security required for MIPv6 signalling is already there in the draft. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 04:05: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 EAA05824 for ; Tue, 17 Oct 2000 04:04:59 -0400 (EDT) Received: from standards (47.234.32.16:4392) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA534D@standards.nortelnetworks.com>; Tue, 17 Oct 2000 3:47:47 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19183 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 03:47:46 -0400 Received: from sj-msg-core-2.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA534B@standards.nortelnetworks.com>; Tue, 17 Oct 2000 3:47:46 -0400 Received: from p7020-img-nt.cisco.com ([64.104.42.108]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id BAA28223; Tue, 17 Oct 2000 01:02:46 -0700 (PDT) X-Sender: fred@flipper X-Mailer: QUALCOMM Windows Eudora Version 5.0 References: <5.0.0.25.2.20001015183014.0283c5c0@flipper> <001101c033ec$f1e096a0$a2388680@kwangwoon.ac.kr> <5.0.0.25.2.20001015183014.0283c5c0@flipper> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.0.0.25.2.20001017065145.03942b50@flipper> Date: Tue, 17 Oct 2000 17:01:26 -0700 Reply-To: Fred Baker Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fred Baker Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: Michael Thomas To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <14827.9724.920401.80705@thomasm-u1.cisco.com> I got this privately, and Michael is willing to take this discussion public. At 08:59 AM 10/16/00 -0700, Michael Thomas wrote: >My general feeling is that for most wireless devices there is no reason >why the mobile would _ever_ be directly attached to its home subnet >router. The reason is pretty straightforward: I want my HA to be a fast >router on housed on a fast network. I definitely do _not_ want it housed >on my true home network because then I'd have to deal with triangular >routing through krufty and slow cable/dsl, not to mention not wanting to >book qos through a last mile technology. The casual security problem will >still be as much a problem in wireless as it is today. Namely, it will be >the exception, not the rule. There are a couple of points to consider here. One is that I tend to think a lot of the discussion in Mobile IP is oriented around radio networks, and it's not in the least obvious to me that radio networks are the only use of it. I'm looking at it for quite another use that could use radios as the last mile, but requires no radios at all, and runs on a pretty large scale. So there is a trap we could fall into here that is somewhat worrisome. Another is largely as Michael says - we want the Home Agent to be somewhere with enough capacity for huge numbers of things to use it. The "optimized" routing helps MIP scale quite a bit, which is an important commercial step. Making the home agents be in routers off in crufty corners of our corporate attics (the non-radio case) defeats a lot of that. In such cases, we will want something more central. I looked through the Hierarchical Mobility draft, and it seems to have the right mix of things - although I have to say it is more a marketing statement about the technology ("it is wonderful and Ericcson is applying for a patent") than a statement about how to do it beyond the need for another bit; we need quite a bit on the routing aspects of the technology. But I think there is a simpler approach that scales more nicely. In DHCP, there is an assumption that there is a DHCP listener on every LAN. That isn't even close to reality, so in routers there is often a feature called a DHCP Helper; it receives the DHCP message and forwards it to an appropriate DHCP server. I submit that having a Home Agent Helper - a process which picks up messages sent to the home agent anycast address and tunnels them to somewhere more central - gives you the right mix of scaling properties and the ability to site home agents appropriately. Similarly, if a mobile access helper anycast address existed, the local router could either be that system, or could tunnel messages to it. If could advise the mobile device of its presence and willingness to act as a care-of address; the mobile node would give this mobile access point a more local care-of address, and said MAP would forward messages directed to it to that more local COA. The only concern I have with putting the COA directly on the mobile device is the need for someone to forward them during handoffs, and this would allow for that. It seems like this "helper" model is not dissimilar to the Hierarchical Mobility model, but simpler. I can write up a draft if someone is interested to explore that. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 05:39: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 FAA06363 for ; Tue, 17 Oct 2000 05:39:19 -0400 (EDT) Received: from standards (47.234.32.16:4468) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA54A3@standards.nortelnetworks.com>; Tue, 17 Oct 2000 5:22:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19653 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 05:22:17 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:53316) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA54A1@standards.nortelnetworks.com>; Tue, 17 Oct 2000 5:22:16 -0400 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 TAA21196; Tue, 17 Oct 2000 19:33:46 +1000 (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 UAA29779; Tue, 17 Oct 2000 20:36:09 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id <4XFQS317>; Tue, 17 Oct 2000 20:36:18 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613C93@eaubrnt018.epa.ericsson.se> Date: Tue, 17 Oct 2000 20:36:16 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: Fred Baker X-cc: ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > I came up with the answer to your question. It takes some work, but it's > there. Review draft-ietf-mobileip-ipv6-12.txt > > One the router advertisements (sections 4.1, 5.6, 5.7, etc), the routers > tell you whether they are willing to be a home agent and/or a foreign > agent. If no neighboring system is willing to be your home agent but there > > is a foreign agent, you are roaming. If there is someone willing to be a > home agent but you cannot authenticate with him, your previous home agent > remains your home agent, and you are roaming. If someone advertises that > he > will be your home agent and you can authenticate with him, you are at > home. > => I'm not sure if I understand what you mean by the foreign agent. Perhaps you have another entity in mind ? Because the current MIPv6 draft does not have foreign agents. > The one thing that bothered me as I read this was an implicit assumption, > perhaps on my part and perhaps on the author's part, that the device has > to > somehow come in contact with its home agent as a neighboring device once > in > a while. I can think of a number of scenarios in which this may not be > true > - imagine a case where you have a telephone mailed to you on the road > because the old one broke. You certainly want to be able to tell the new > phone the old phone's information and have it stick. Or imagine a device > which is permanently roaming - it never actually is at home. You would > want > to configure a home agent address somehow. I trust that in these cases the > > protocol is not required. > => You never need to configure a Home Agent address. The current draft specifies a Dynamic Home Agent Discovery mechanism. All you need to configure is a Home Address. I believe MIPv6 can support the scenario you mentioned provided the MN knows its Home Address. Which is a reasonable assumption IMO. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 07:02: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 HAA07519 for ; Tue, 17 Oct 2000 07:02:10 -0400 (EDT) Received: from standards (47.234.32.16:4468) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA557F@standards.nortelnetworks.com>; Tue, 17 Oct 2000 6:44:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19885 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 06:44:33 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA555C@standards.nortelnetworks.com>; Tue, 17 Oct 2000 6:34:32 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07001; Tue, 17 Oct 2000 06:46:19 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200010171046.GAA07001@ietf.org> Date: Tue, 17 Oct 2000 06:46:19 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: [MOBILE-IP] I-D ACTION:draft-mkhalil-mobileip-ipv6-handoff-00.txt X-cc: mib-wg@nnsc.nsf.net To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : AAA Interface for IPv6 Handoff Author(s) : M. Khalil, H. Akhtar, K. Pillai, E. Qaddoura Filename : draft-mkhalil-mobileip-ipv6-handoff-00.txt Pages : 16 Date : 16-Oct-00 This draft outlines a protocol to achieve minimal disruption during Mobile IPv6 handoff. Minimal disruption during handoff is required by Mobile IPv6 to reduce the window of data loss experienced by a MN (Mobile Node) when moving between access networks that may belong to same or different administrative domains. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mkhalil-mobileip-ipv6-handoff-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-mkhalil-mobileip-ipv6-handoff-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-mkhalil-mobileip-ipv6-handoff-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: <20001016145518.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mkhalil-mobileip-ipv6-handoff-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mkhalil-mobileip-ipv6-handoff-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001016145518.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 08:04: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 IAA08832 for ; Tue, 17 Oct 2000 08:04:12 -0400 (EDT) Received: from standards (47.234.32.16:4386) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA55D7@standards.nortelnetworks.com>; Tue, 17 Oct 2000 7:46:51 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20036 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 07:46:51 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA55D1@standards.nortelnetworks.com>; Tue, 17 Oct 2000 7:36:51 -0400 Received: from adventure.e-venture.it (adventure.e-venture.it [193.70.196.1]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id GAA11766 for ; Tue, 17 Oct 2000 06:51:56 -0500 (CDT) Received: (qmail 13383 invoked from network); 17 Oct 2000 00:33:44 -0000 Received: from unknown (HELO sdn-ar-001tnknoxP160.dialsprint.net??206.133.83.96?) (206.133.83.96) by adventure.e-venture.it with SMTP; 17 Oct 2000 00:33:44 -0000 Received: from by sdn-ar-001tnknoxP160.dialsprint.net with ESMTP; Mon, 16 Oct 2000 20:47:10 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <0000080e05f5$0000091e$00004db9@> Date: Mon, 16 Oct 2000 20:46:56 -0400 Reply-To: chonged@EARTHLINK.NET Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: chonged@EARTHLINK.NET Subject: [MOBILE-IP] Viagra Right Online!! 19897 X-To: Undisclosed.Recipients@hosaka.smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: quoted-printable = Get VIAGRA



the breakthrough medication for impotence

delivered to your mailbox...



..without leaving your computer.



In less than 5 minutes you can complete the on-line consultation and in
many cases have the medication in 24 hours.



From our website to your mailbox.

On-line consultation for treatment of compromised sexual function.



Convenient...affordable....confidential.

We ship VIAGRA worldwide at US prices.



To Order Visit:http://www.ecommercepalace.com/viagra.cfm?affiliateid=3DD= D10425









Under Bill 1618 TITLE III passed by the 105th U.S. Congress

this letter can not be considered spam as long as we include:

Contact information & a Remove Link.

TO REMOVE CLICK ON remove@webstorealley.com











































 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 08:04: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 IAA08846 for ; Tue, 17 Oct 2000 08:04:15 -0400 (EDT) Received: from standards (47.234.32.16:4386) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5601@standards.nortelnetworks.com>; Tue, 17 Oct 2000 7:48:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20093 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 07:48:36 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA55FC@standards.nortelnetworks.com>; Tue, 17 Oct 2000 7:48:36 -0400 Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id e9HC3gt06767 for ; Tue, 17 Oct 2000 14:03:42 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Oct 17 13:23:32 2000 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id <4Y418R09>; Tue, 17 Oct 2000 12:55:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <5F05C89FB2F8D211B6430008C791912703EA81EB@esealnt190> Date: Tue, 17 Oct 2000 12:52:39 +0200 Reply-To: "Karim El-Malki (ERA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Karim El-Malki (ERA)" Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: Fred Baker To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello Fred > There are a couple of points to consider here. One is that I > tend to think > a lot of the discussion in Mobile IP is oriented around radio > networks, and > it's not in the least obvious to me that radio networks are > the only use of > it. I'm looking at it for quite another use that could use > radios as the > last mile, but requires no radios at all, and runs on a > pretty large scale. > So there is a trap we could fall into here that is somewhat worrisome. I understand your point but there is no assumption in the discussions as to where the radio network lies (if any) with respect to mobility agents. On the other hand it is also clear that radio is very important for mobility so it is good that we take it into consideration and discuss it. > Another is largely as Michael says - we want the Home Agent > to be somewhere > with enough capacity for huge numbers of things to use it. > The "optimized" > routing helps MIP scale quite a bit, which is an important > commercial step. > Making the home agents be in routers off in crufty corners of > our corporate > attics (the non-radio case) defeats a lot of that. In such > cases, we will > want something more central. Are you still referring to MIPv6? Correct me if I'm misunderstanding, but if you do use Route Optimisation the location of the HA is not so important. > I looked through the Hierarchical Mobility draft, and it > seems to have the > right mix of things - although I have to say it is more a marketing > statement about the technology ("it is wonderful and Ericcson > is applying > for a patent") than a statement about how to do it beyond the need for > another bit; we need quite a bit on the routing aspects of > the technology. > But I think there is a simpler approach that scales more nicely. I guess you are referring to draft-ietf-mobileip-hmipv6-00? I think it has nothing to do with a marketing draft so I wonder what you are referring to specifically. It is authored by people employed by Ericsson and INRIA who have already an implementation. Since, as I seem to understand, we are not here representing or advertising companies I also don't think your statement on Ericsson is relevant. But I do agree with the "it is wonderful" bit! > Similarly, if a mobile access helper anycast address existed, > the local > router could either be that system, or could tunnel messages to it. If > could advise the mobile device of its presence and > willingness to act as a > care-of address; the mobile node would give this mobile > access point a more > local care-of address, and said MAP would forward messages > directed to it > to that more local COA. The only concern I have with putting the COA > directly on the mobile device is the need for someone to forward them > during handoffs, and this would allow for that. It seems like > this "helper" > model is not dissimilar to the Hierarchical Mobility model, > but simpler. It sounds very similar to the current HMIPv6 proposal. The same effect can be achieved by the existing draft. I'm not quite sure I understand why it is simpler to use 2 CoAs (one local for the MAP and one for the HA and CNs), anyhow you can do that in the existing proposal. The use of anycast addressing was considered for MAP discovery when we wrote the draft. The nice thing with router advertisements is that you can have the option of more than one MAP to choose from based on their distance and their current loading. This information is encoded in the MAP option. I don't believe you can achieve that using anycast. Plus with subnet anycast you need to know the prefix of the link that the MAP is located on. Regarding the handoff issue, there is another draft that was included in the original proposal but is now part of the handoffs work (draft-elmalki-handoffsv6-00). There are other drafts also being discussed. I hope this addresses your concerns. Regards /Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 08:42: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 IAA10009 for ; Tue, 17 Oct 2000 08:42:08 -0400 (EDT) Received: from standards (47.234.32.16:4386) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5887@standards.nortelnetworks.com>; Tue, 17 Oct 2000 8:24:47 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20944 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 08:24:47 -0400 Received: from qhars002.nortel.com (47.101.112.102:57976) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5885@standards.nortelnetworks.com>; Tue, 17 Oct 2000 8:24:47 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Tue, 17 Oct 2000 13:39:41 +0100 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Tue, 17 Oct 2000 07:39:10 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id <4VMDATMW>; Tue, 17 Oct 2000 07:39:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03837.39288F10" Message-ID: <40DC7CF03BDDD3118F3D0000F806EEEC4F3417@zrchb199.us.nortel.com> Date: Tue, 17 Oct 2000 07:38:59 -0500 Reply-To: Haseeb Akhtar Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Haseeb Akhtar Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: Fred Baker 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_01C03837.39288F10 Content-Type: text/plain Fred, I would agree with you on the objective and portions of the solution. At least, the part about having an Anycast address for HA discovery. This would specially be useful for the IPv6 model where there is no FA. Haseeb > -----Original Message----- > From: Fred Baker [SMTP:fred@CISCO.COM] > Sent: Tuesday, October 17, 2000 7:01 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] MIPv6 node location detection > > I got this privately, and Michael is willing to take this discussion > public. > > At 08:59 AM 10/16/00 -0700, Michael Thomas wrote: > >My general feeling is that for most wireless devices there is no reason > >why the mobile would _ever_ be directly attached to its home subnet > >router. The reason is pretty straightforward: I want my HA to be a fast > >router on housed on a fast network. I definitely do _not_ want it housed > >on my true home network because then I'd have to deal with triangular > >routing through krufty and slow cable/dsl, not to mention not wanting to > >book qos through a last mile technology. The casual security problem will > >still be as much a problem in wireless as it is today. Namely, it will be > >the exception, not the rule. > > There are a couple of points to consider here. One is that I tend to think > a lot of the discussion in Mobile IP is oriented around radio networks, > and > it's not in the least obvious to me that radio networks are the only use > of > it. I'm looking at it for quite another use that could use radios as the > last mile, but requires no radios at all, and runs on a pretty large > scale. > So there is a trap we could fall into here that is somewhat worrisome. > > Another is largely as Michael says - we want the Home Agent to be > somewhere > with enough capacity for huge numbers of things to use it. The "optimized" > routing helps MIP scale quite a bit, which is an important commercial > step. > Making the home agents be in routers off in crufty corners of our > corporate > attics (the non-radio case) defeats a lot of that. In such cases, we will > want something more central. > > I looked through the Hierarchical Mobility draft, and it seems to have the > right mix of things - although I have to say it is more a marketing > statement about the technology ("it is wonderful and Ericcson is applying > for a patent") than a statement about how to do it beyond the need for > another bit; we need quite a bit on the routing aspects of the technology. > But I think there is a simpler approach that scales more nicely. > > In DHCP, there is an assumption that there is a DHCP listener on every > LAN. > That isn't even close to reality, so in routers there is often a feature > called a DHCP Helper; it receives the DHCP message and forwards it to an > appropriate DHCP server. I submit that having a Home Agent Helper - a > process which picks up messages sent to the home agent anycast address and > tunnels them to somewhere more central - gives you the right mix of > scaling > properties and the ability to site home agents appropriately. > > Similarly, if a mobile access helper anycast address existed, the local > router could either be that system, or could tunnel messages to it. If > could advise the mobile device of its presence and willingness to act as a > care-of address; the mobile node would give this mobile access point a > more > local care-of address, and said MAP would forward messages directed to it > to that more local COA. The only concern I have with putting the COA > directly on the mobile device is the need for someone to forward them > during handoffs, and this would allow for that. It seems like this > "helper" > model is not dissimilar to the Hierarchical Mobility model, but simpler. > > I can write up a draft if someone is interested to explore that. ------_=_NextPart_001_01C03837.39288F10 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] MIPv6 node location detection

Fred,

I would agree with = you on the objective and portions of the solution. At least, the part = about having an Anycast address for HA discovery. This would specially = be useful for the IPv6 model where there is no FA.

Haseeb

    -----Original Message-----
    From:   Fred Baker [SMTP:fred@CISCO.COM]
    Sent:   Tuesday, October 17, 2000 7:01 PM
    To:     MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: [MOBILE-IP] MIPv6 node location = detection

    I got this privately, and Michael is = willing to take this discussion public.

    At 08:59 AM 10/16/00 -0700, Michael = Thomas wrote:
    >My general feeling is that for = most wireless devices there is no reason
    >why the mobile would _ever_ be = directly attached to its home subnet
    >router. The reason is pretty = straightforward: I want my HA to be a fast
    >router on housed on a fast = network. I definitely do _not_ want it housed
    >on my true home network because = then I'd have to deal with triangular
    >routing through krufty and slow = cable/dsl, not to mention not wanting to
    >book qos through a last mile = technology. The casual security problem will
    >still be as much a problem in = wireless as it is today. Namely, it will be
    >the exception, not the = rule.

    There are a couple of points to = consider here. One is that I tend to think
    a lot of the discussion in Mobile IP = is oriented around radio networks, and
    it's not in the least obvious to me = that radio networks are the only use of
    it. I'm looking at it for quite = another use that could use radios as the
    last mile, but requires no radios at = all, and runs on a pretty large scale.
    So there is a trap we could fall into = here that is somewhat worrisome.

    Another is largely as Michael says - = we want the Home Agent to be somewhere
    with enough capacity for huge numbers = of things to use it. The "optimized"
    routing helps MIP scale quite a bit, = which is an important commercial step.
    Making the home agents be in routers = off in crufty corners of our corporate
    attics (the non-radio case) defeats a = lot of that. In such cases, we will
    want something more central.

    I looked through the Hierarchical = Mobility draft, and it seems to have the
    right mix of things - although I have = to say it is more a marketing
    statement about the technology = ("it is wonderful and Ericcson is applying
    for a patent") than a statement = about how to do it beyond the need for
    another bit; we need quite a bit on = the routing aspects of the technology.
    But I think there is a simpler = approach that scales more nicely.

    In DHCP, there is an assumption that = there is a DHCP listener on every LAN.
    That isn't even close to reality, so = in routers there is often a feature
    called a DHCP Helper; it receives the = DHCP message and forwards it to an
    appropriate DHCP server. I submit = that having a Home Agent Helper - a
    process which picks up messages sent = to the home agent anycast address and
    tunnels them to somewhere more = central - gives you the right mix of scaling
    properties and the ability to site = home agents appropriately.

    Similarly, if a mobile access helper = anycast address existed, the local
    router could either be that system, = or could tunnel messages to it. If
    could advise the mobile device of its = presence and willingness to act as a
    care-of address; the mobile node = would give this mobile access point a more
    local care-of address, and said MAP = would forward messages directed to it
    to that more local COA. The only = concern I have with putting the COA
    directly on the mobile device is the = need for someone to forward them
    during handoffs, and this would allow = for that. It seems like this "helper"
    model is not dissimilar to the = Hierarchical Mobility model, but simpler.

    I can write up a draft if someone is = interested to explore that.

------_=_NextPart_001_01C03837.39288F10-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 10:13: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 KAA12461 for ; Tue, 17 Oct 2000 10:13:57 -0400 (EDT) Received: from standards (47.234.32.16:1249) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5941@standards.nortelnetworks.com>; Tue, 17 Oct 2000 9:56:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21185 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 09:56:41 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA593F@standards.nortelnetworks.com>; Tue, 17 Oct 2000 9:56:40 -0400 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 e9HEB9s33678; Tue, 17 Oct 2000 16:11:11 +0200 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 QAA24722; Tue, 17 Oct 2000 16:11:08 +0200 (MET DST) 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 QAA73291; Tue, 17 Oct 2000 16:15:30 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200010171415.QAA73291@givry.rennes.enst-bretagne.fr> Date: Tue, 17 Oct 2000 16:15:29 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: "John F. Leser" X-cc: ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Fri, 13 Oct 2000 10:14:26 EDT. In your previous mail you wrote: Reading through section 10.4 of the MIPv6 draft (version 12), I get the impression that: 1. Movement detection is not a simple problem to solve. The draft doesn't really specifiy what method should be used. => there are many different methods, some of them are (too) slow, some of them can detect movements when there is no movement, this can be a problem or not... I think we need to get results from fast/smart/... handoff special group and from implemention experiences. 2. Seeing an adverisement from a router with a different prefix is not a good way to detect movement. => I agree but the other way is not better. The preferred movement detection method seems to be loss of reachability of the MN's default router, => this is not good if there are more than one router and of course is very bad if the number of potential default routers is large enough... which is noticed through neighbor unreachability detection => which uses neighbor solicitations, not router solicitations ! and/or use of the router advertisement interval option. => this point should be added into neighbor discovery specs (ie. it is useful in general, not only for mobility). > > I also can't find RFC or draft which define exactly address list in a > > MIPv6 MN. A IPv6 node have a address list and every prefix has lifetime => in *theory* the list is the union of local prefixes and home prefixes, both are in router advertisements on the local link and through the tunnel with the home agent with the according lifetimes. In order to get the whole list ASAP someone suggested in this list that the home agent sends router advertisements to the MN when a home registration is done. 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)... An open question is what to do with DHCPv6? Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 10:24: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 KAA12667 for ; Tue, 17 Oct 2000 10:24:12 -0400 (EDT) Received: from standards (47.234.32.16:1249) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5963@standards.nortelnetworks.com>; Tue, 17 Oct 2000 10:00:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21224 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 10:00:17 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA595F@standards.nortelnetworks.com>; Tue, 17 Oct 2000 10:00:14 -0400 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 e9HEEls48614; Tue, 17 Oct 2000 16:14:47 +0200 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 QAA24848; Tue, 17 Oct 2000 16:14:47 +0200 (MET DST) 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 QAA73331; Tue, 17 Oct 2000 16:19:08 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200010171419.QAA73331@givry.rennes.enst-bretagne.fr> Date: Tue, 17 Oct 2000 16:19:08 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: Alexandru Petrescu X-cc: ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Fri, 13 Oct 2000 17:42:37 +0200. In your previous mail you wrote: I think this would not work if home net and visited net both renumber at the same time and take each other's prefixes. => this is explicitely forbidden because many things (not only mobility) will break if two prefixes are quickly swapped... Francis.Dupont@enst-bretagne.fr PS: prefixes are not ephemeral, default lifetimes are in days and renumbering "hold down" in months. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 10:24: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 KAA12681 for ; Tue, 17 Oct 2000 10:24:13 -0400 (EDT) Received: from standards (47.234.32.16:1249) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA59B8@standards.nortelnetworks.com>; Tue, 17 Oct 2000 10:06:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21338 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 10:06:41 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA59B6@standards.nortelnetworks.com>; Tue, 17 Oct 2000 10:06:40 -0400 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 e9HEJws32655; Tue, 17 Oct 2000 16:19:58 +0200 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 QAA25028; Tue, 17 Oct 2000 16:19:57 +0200 (MET DST) 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 QAA73368; Tue, 17 Oct 2000 16:24:19 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200010171424.QAA73368@givry.rennes.enst-bretagne.fr> Date: Tue, 17 Oct 2000 16:24:19 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: Lars Henrik Petander To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Sat, 14 Oct 2000 11:30:22 +0300. In your previous mail you wrote: Based on my experiences developing the movement detection part of the MIPL implementation, a combination of eager cell switching that is moderated by the list of known routers combined with router unreachbility detection based on the router interval option works well in most cases. => this works well in an environment where mobility is some kind of cellular thing. There are other types of movements, some of them very easy to detect like physical interface (ex)changes. Someone proposed the final solution: use PPP and bring it down and up during movements (not more silly then anything is cellular :-). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 10:36: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 KAA12988 for ; Tue, 17 Oct 2000 10:36:08 -0400 (EDT) Received: from standards (47.234.32.16:1249) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA59EE@standards.nortelnetworks.com>; Tue, 17 Oct 2000 10:09:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21411 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 10:09:08 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA59EC@standards.nortelnetworks.com>; Tue, 17 Oct 2000 10:09:08 -0400 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 e9HENns48610; Tue, 17 Oct 2000 16:23:49 +0200 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 QAA25148; Tue, 17 Oct 2000 16:23:48 +0200 (MET DST) 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 QAA73405; Tue, 17 Oct 2000 16:28:10 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200010171428.QAA73405@givry.rennes.enst-bretagne.fr> Date: Tue, 17 Oct 2000 16:28:10 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: Brian Zill X-cc: "Hesham Soliman (EPA)" , ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Sun, 15 Oct 2000 17:28:44 PDT. In your previous mail you wrote: Now the MIPv6 draft is a little weak regarding how this authorization should be done, but I think that's a problem for the mobile ip working group. => I disagree, MIPv6 mandates IPsec (AH in tunnel mode for authentication, integrity and replay protection). Perhaps there is a conflict between PPP authentication, DHCPv6, AAA and IPsec but this is not from a lack of protocols/tools (:-)... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 10:36: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 KAA12994 for ; Tue, 17 Oct 2000 10:36:09 -0400 (EDT) Received: from standards (47.234.32.16:1249) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5A4B@standards.nortelnetworks.com>; Tue, 17 Oct 2000 10:16:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21533 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 10:16:02 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5A49@standards.nortelnetworks.com>; Tue, 17 Oct 2000 10:15:55 -0400 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 e9HEUOs48085; Tue, 17 Oct 2000 16:30:25 +0200 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 QAA25391; Tue, 17 Oct 2000 16:30:20 +0200 (MET DST) 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 QAA73469; Tue, 17 Oct 2000 16:34:42 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200010171434.QAA73469@givry.rennes.enst-bretagne.fr> Date: Tue, 17 Oct 2000 16:34:42 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: "John F. Leser" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Mon, 16 Oct 2000 12:55:10 EDT. In your previous mail you wrote: I agree here - if you're going to keep your network in a "being renumbered" state, why not just continue to advertise the old prefix as on-link, but with 0 valid lifetime. This would make it clear to any node returning to the home network that something has changed. => this is not only useful for mobile node... I think this will be with at least a SHOULD in the "how to renumber" guide. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 10: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 KAA13004 for ; Tue, 17 Oct 2000 10:36:10 -0400 (EDT) Received: from standards (47.234.32.16:1249) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5A60@standards.nortelnetworks.com>; Tue, 17 Oct 2000 10:16:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21347 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 10:16:54 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA59BD@standards.nortelnetworks.com>; Tue, 17 Oct 2000 10:06:53 -0400 Received: from Afds01.acerdarwin.com.au (acerfo.lnk.telstra.net [139.130.120.95]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id JAA12466 for ; Tue, 17 Oct 2000 09:21:56 -0500 (CDT) Received: from JGpFqNJkW (2Cust5.tnt1.chi1.da.uu.net [63.21.62.133]) by Afds01.acerdarwin.com.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id R2YDNWJ8; Tue, 17 Oct 2000 23:52:12 +0930 Message-ID: Date: Tue, 17 Oct 2000 11:04:38 AM Reply-To: o8gXWoUJm@HELCOM.ES Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: o8gXWoUJm@HELCOM.ES Subject: [MOBILE-IP] An Incredible Lead Generation Tool X-To: hei5xq@chestyi.co.uk To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM D O N ' T H E S I T A T E - E-Marketing is the most effective and fastest way to market anywhere... PERIOD! When your ready to seriously market your product or opportunity we offer the tools to help you succeed. Our research has found that many people have tried one or more of the following internet advertising methods..... Free Classifieds? (Don't work anymore) Web Site? (Takes thousands of visitors) Banners? (Expensive and losing their punch) E-Zine? (Hope they have a *huge* subscriber list) Search Engines? (Forget it, unless you're in the top 20) S O W H A T W I L L W O R K ? Although often misunderstood, there is one method that has proven to succeed time-after-time. E - M A I L M A R K E T I N G ! ! IT'S A FACT... It if you're not using your computer to generate income, GOOD income, you're leaving money on the table. Here's what the experts have to say about E-Mail Marketing: *"E-mail is an incredible lead generation tool" -Crains Magazine *"A gold mine for those who can take advantage of bulk e-mail programs" - The New York Times *"Blows away traditional Mailing" - Advertising Age Here's an example of your potential earnings if you have a product or service that brings you a profit of around $30. Remember, on the Internet, you can make money 7 days a week, 24 hours a day... even while you sleep, orders come from all over the world! Orders: Per Day Weekly Monthly Yearly 1 $ 210 $ 840 $ 10,080 2 420 1,680 20,160 3 630 2,520 30,240 5 1,050 4,200 50,400 10 2,100 8,400 100,000 15 3,150 12,600 151,200 THE QUESTION IS... how do you generate those orders? The least expensive and fastest way is through E-Mail Marketing. Here are a few things that you'll be enjoying when you purchase. * A headache-free email promotion! * We handle all aspects of the mailing. Including targeting, delivery and confirmation! * Access to our staff of marketing professionals that are eager to assist in growing your business! * Total protection for your ISP & Email account. We handle everything. Take Advantage Of Our Specials Now 708 401 1688 ******************************************************************* You received this message because you visited one of our web sites or requested information. To be removed please send an email to: jaqrv19@yemenmail.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 10:55: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 KAA13378 for ; Tue, 17 Oct 2000 10:55:17 -0400 (EDT) Received: from standards (47.234.32.16:1249) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5B92@standards.nortelnetworks.com>; Tue, 17 Oct 2000 10:38:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21968 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 10:38:10 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5B90@standards.nortelnetworks.com>; Tue, 17 Oct 2000 10:38:09 -0400 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 e9HErCs21875; Tue, 17 Oct 2000 16:53:12 +0200 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 QAA26203; Tue, 17 Oct 2000 16:53:11 +0200 (MET DST) 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 QAA73556; Tue, 17 Oct 2000 16:57:33 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200010171457.QAA73556@givry.rennes.enst-bretagne.fr> Date: Tue, 17 Oct 2000 16:57:33 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: Fred Baker To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Tue, 17 Oct 2000 17:01:26 PDT. <5.0.0.25.2.20001017065145.03942b50@flipper> In your previous mail you wrote: I got this privately, and Michael is willing to take this discussion public. At 08:59 AM 10/16/00 -0700, Michael Thomas wrote: >My general feeling is that for most wireless devices there is no reason >why the mobile would _ever_ be directly attached to its home subnet >router. The reason is pretty straightforward: I want my HA to be a fast >router on housed on a fast network. => for some other reasons I believe this kind of "virtual" home link will be common. For instance if mobile IPv6 is used for mobile phones then the home link will be a set of large boxes inside the core of the operator and mobile nodes will be *never* at home (in fact the home link doesn't need to physically exist then I call this a "virtual" home link). There are a couple of points to consider here. One is that I tend to think a lot of the discussion in Mobile IP is oriented around radio networks, and it's not in the least obvious to me that radio networks are the only use of it. => I agree, even the future of IPv6 seems to be 3G mobile phone, my favorite mobile IP usage is to exchange a 9600bits/s wireless expensive PPP for a 100Mbits/s free Ethernet. Only mobile IP can do that! I looked through the Hierarchical Mobility draft, and it seems to have the right mix of things - although I have to say it is more a marketing statement about the technology ("it is wonderful and Ericcson is applying for a patent") than a statement about how to do it beyond the need for another bit; we need quite a bit on the routing aspects of the technology. But I think there is a simpler approach that scales more nicely. => you are a bit unfair with hierarchical mobility. This is a good idea and some proposals are already merged and implemented (ie. it is no more academic paper or industrial marketing :-). In DHCP, there is an assumption that there is a DHCP listener on every LAN. That isn't even close to reality, so in routers there is often a feature called a DHCP Helper; it receives the DHCP message and forwards it to an appropriate DHCP server. => this exists in DHCPv6 as "relays" and multicast can optionally be used in order to find servers. I submit that having a Home Agent Helper - a process which picks up messages sent to the home agent anycast address and tunnels them to somewhere more central - gives you the right mix of scaling properties and the ability to site home agents appropriately. => I think the current home agent discovery in mobile IPv6 (which uses an anycast address in the home prefix) has already the good properties (it just needs to get some numbers from IANA to be usable :-). Similarly, if a mobile access helper anycast address existed, the local router could either be that system, or could tunnel messages to it. If could advise the mobile device of its presence and willingness to act as a care-of address; the mobile node would give this mobile access point a more local care-of address, and said MAP would forward messages directed to it to that more local COA. => this is the hierarchical mobility idea: hide local movements... The only concern I have with putting the COA directly on the mobile device is the need for someone to forward them during handoffs, and this would allow for that. It seems like this "helper" model is not dissimilar to the Hierarchical Mobility model, but simpler. => I've seen an answer by a hierarchical mobility person... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 11:33: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 LAA14283 for ; Tue, 17 Oct 2000 11:33:29 -0400 (EDT) Received: from standards (47.234.32.16:1249) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5C39@standards.nortelnetworks.com>; Tue, 17 Oct 2000 11:16:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22191 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 11:16:14 -0400 Received: from ebene.inrialpes.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5C37@standards.nortelnetworks.com>; Tue, 17 Oct 2000 11:16:14 -0400 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 RAA01771; Tue, 17 Oct 2000 17:31:20 +0200 (MET DST) Received: from inrialpes.fr (localhost [127.0.0.1]) by glandon.inrialpes.fr (8.8.7/8.8.5) with ESMTP id RAA10972; Tue, 17 Oct 2000 17:31:19 +0200 (MET DST) X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <5.0.0.25.2.20001015183014.0283c5c0@flipper> <001101c033ec$f1e096a0$a2388680@kwangwoon.ac.kr> <5.0.0.25.2.20001015183014.0283c5c0@flipper> <5.0.0.25.2.20001017065145.03942b50@flipper> Content-Type: multipart/alternative; boundary="------------0FCF6E63116AAF647E004E3A" Message-ID: <39EC70C7.B273EF12@inrialpes.fr> Date: Tue, 17 Oct 2000 17:31:19 +0200 Reply-To: Claude.Castelluccia@INRIALPES.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Claude Castelluccia Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: Fred Baker To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --------------0FCF6E63116AAF647E004E3A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Fred, Fred Baker wrote: > > I looked through the Hierarchical Mobility draft, and it seems to have the > right mix of things - although I have to say it is more a marketing > statement about the technology ("it is wonderful and Ericcson is applying > for a patent") than a statement about how to do it beyond the need for > another bit; we need quite a bit on the routing aspects of the technology. As a co-author of the draft, I of course do not agree with you. There is nothing marketing about this draft. We describe in detail our protocol. What do you thing is missing in this draft? We will be very happy to make any useful additions that will make it more technical... BTW we also have an implementation ( that can be downloaded at http://www.inrialpes.fr/planete/)... FYI I am not from Ericsson but from INRIA. INRIA is a public research center. We are not selling anything and we do not care about marketing... > > But I think there is a simpler approach that scales more nicely. this looks very much like a marketing statement :-) > > > In DHCP, there is an assumption that there is a DHCP listener on every LAN. > That isn't even close to reality, so in routers there is often a feature > called a DHCP Helper; it receives the DHCP message and forwards it to an > appropriate DHCP server. I submit that having a Home Agent Helper - a > process which picks up messages sent to the home agent anycast address and > tunnels them to somewhere more central - gives you the right mix of scaling > properties and the ability to site home agents appropriately. > > Similarly, if a mobile access helper anycast address existed, the local > router could either be that system, or could tunnel messages to it. If > could advise the mobile device of its presence and willingness to act as a > care-of address; the mobile node would give this mobile access point a more > local care-of address, and said MAP would forward messages directed to it > to that more local COA. The only concern I have with putting the COA > directly on the mobile device is the need for someone to forward them > during handoffs, and this would allow for that. It seems like this "helper" > model is not dissimilar to the Hierarchical Mobility model, but simpler. > I am not sure I understand everthing but from what I have just read this does not look simpler than HMIPv6. HMIPv6 is just a simple extension to Mobile IPv6...I don't think one can do simpler ;-) > > I can write up a draft if someone is interested to explore that. yes, I think that would be really interesting and useful... regards, Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------0FCF6E63116AAF647E004E3A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Fred,

Fred Baker wrote:

 
I looked through the Hierarchical Mobility draft, and it seems to have the
right mix of things - although I have to say it is more a marketing
statement about the technology ("it is wonderful and Ericcson is applying
for a patent") than a statement about how to do it beyond the need for
another bit; we need quite a bit on the routing aspects of the technology.
As a co-author of the draft, I of course do not agree with you.
There is nothing marketing about this draft. We describe in detail
our protocol.
What do you thing is missing in this draft? We will be very happy
to make any useful additions that will make it more technical...
BTW we also have an implementation ( that can be
downloaded at http://www.inrialpes.fr/planete/)...
FYI I am not from Ericsson but from INRIA. INRIA is a public
research center. We are not selling anything and we do not care about marketing...
 
But I think there is a simpler approach that scales more nicely.
this looks very much like a marketing statement :-)
 

In DHCP, there is an assumption that there is a DHCP listener on every LAN.
That isn't even close to reality, so in routers there is often a feature
called a DHCP Helper; it receives the DHCP message and forwards it to an
appropriate DHCP server. I submit that having a Home Agent Helper - a
process which picks up messages sent to the home agent anycast address and
tunnels them to somewhere more central - gives you the right mix of scaling
properties and the ability to site home agents appropriately.

Similarly, if a mobile access helper anycast address existed, the local
router could either be that system, or could tunnel messages to it. If
could advise the mobile device of its presence and willingness to act as a
care-of address; the mobile node would give this mobile access point a more
local care-of address, and said MAP would forward messages directed to it
to that more local COA. The only concern I have with putting the COA
directly on the mobile device is the need for someone to forward them
during handoffs, and this would allow for that. It seems like this "helper"
model is not dissimilar to the Hierarchical Mobility model, but simpler.
 

I am not sure  I understand everthing but from what I have just read this
does not look simpler than HMIPv6.
HMIPv6 is just a simple extension to Mobile IPv6...I don't think one
can do simpler ;-)
 
 
I can write up a draft if someone is interested to explore that.
yes, I think that would be really interesting and useful...

regards,

Claude. 

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------0FCF6E63116AAF647E004E3A-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 11:42: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 LAA14542 for ; Tue, 17 Oct 2000 11:42:03 -0400 (EDT) Received: from standards (47.234.32.16:1249) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5C82@standards.nortelnetworks.com>; Tue, 17 Oct 2000 11:24:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22190 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 11:24:52 -0400 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5C36@standards.nortelnetworks.com>; Tue, 17 Oct 2000 11:14:50 -0400 Received: from esebh02nok.ntc.nokia.com (esebh02nok.ntc.nokia.com [131.228.118.151]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e9HFTtP17774 for ; Tue, 17 Oct 2000 18:29:55 +0300 (EET DST) Received: by esebh02nok with Internet Mail Service (5.5.2652.78) id ; Tue, 17 Oct 2000 17:37:09 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <01D91AFB08B6D211BFD00008C7EABAE105855B28@eseis04nok> Date: Tue, 17 Oct 2000 17:37:06 +0300 Reply-To: jarno.rajahalme@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jarno Rajahalme Subject: Re: [MOBILE-IP] MIPv6 node location detection To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Francis Dupont [mailto:Francis.Dupont@ENST-BRETAGNE.FR] wrote: > - 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. NAI extensions seem to be in scope, at least for Mobile IPv4. What if the domain portion (or part of) of the NAI could be resolved to the home prefix(es)? The TTL of each RR could reflect the lifetime of the prefix, and could also be zero. > An open question is what to do with DHCPv6? > Are NAIs already integral part of DHCPv6? With regards, Jarno Rajahalme From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 13:12: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 NAA17083 for ; Tue, 17 Oct 2000 13:12:32 -0400 (EDT) Received: from standards (47.234.32.16:1249) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5DB5@standards.nortelnetworks.com>; Tue, 17 Oct 2000 12:55:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22694 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 12:55:22 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5DB3@standards.nortelnetworks.com>; Tue, 17 Oct 2000 12:55:22 -0400 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 e9HGqls18552; Tue, 17 Oct 2000 18:52:47 +0200 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 SAA00258; Tue, 17 Oct 2000 18:52:46 +0200 (MET DST) 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 SAA74299; Tue, 17 Oct 2000 18:57:09 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200010171657.SAA74299@givry.rennes.enst-bretagne.fr> Date: Tue, 17 Oct 2000 18:57:09 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: jarno.rajahalme@NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Tue, 17 Oct 2000 17:37:06 +0300. <01D91AFB08B6D211BFD00008C7EABAE105855B28@eseis04nok> In your previous mail you wrote: Francis Dupont [mailto:Francis.Dupont@ENST-BRETAGNE.FR] wrote: > - 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. NAI extensions seem to be in scope, at least for Mobile IPv4. => do you propose to use the realm part of NAIs has the default name? This seems a natural way to do this... What if the domain portion (or part of) of the NAI could be resolved to the home prefix(es)? => it can point to the anycast address(es) reserved for home agents but this kind of convention should be specified in a new document (one more in the stack waiting mobile IPv6 publication as PS :-). The TTL of each RR could reflect the lifetime of the prefix, and could also be zero. => I think we should keep the standard (ie. DNS) meaning of RR TTL. There is no need to have a too complex (ie too smart) thing and current resolvers don't give the TTL (they should IMHO). > An open question is what to do with DHCPv6? Are NAIs already integral part of DHCPv6? => not in the current specs but there is a discussion about client identifier then NAIs should not be far. In fact this identifier should be derived from the NAI (there is an identifier per link/interface)... IMHO NAI should be merged with other identifiers, like this one or the user_FQDN ID payload of IKE or Subject(Alt)Name in certificates. Of course the central user of NAIs is AAA... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 13:50: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 NAA17809 for ; Tue, 17 Oct 2000 13:50:35 -0400 (EDT) Received: from standards (47.234.32.16:1249) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5E7A@standards.nortelnetworks.com>; Tue, 17 Oct 2000 13:33:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22935 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 13:33:38 -0400 Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5E78@standards.nortelnetworks.com>; Tue, 17 Oct 2000 13:33:38 -0400 Received: from gopal.cisco.com (dhcp-171-70-57-69.cisco.com [171.70.57.69]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA11021; Tue, 17 Oct 2000 10:48:37 -0700 (PDT) X-Sender: gdommety@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.3.2.7.2.20001017104725.00cb7db0@omega.cisco.com> Date: Tue, 17 Oct 2000 10:50:32 -0700 Reply-To: Gopal Dommety Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gopal Dommety Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: "Karim El-Malki (ERA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <5F05C89FB2F8D211B6430008C791912703EA81EB@esealnt190> Hello: Trying to catchup on my email, so if my comments are off-base, my apologies. >> I looked through the Hierarchical Mobility draft, and it >> seems to have the >> right mix of things - although I have to say it is more a marketing >> statement about the technology ("it is wonderful and Ericcson >> is applying >> for a patent") than a statement about how to do it beyond the need for >> another bit; we need quite a bit on the routing aspects of >> the technology. >> But I think there is a simpler approach that scales more nicely. > >I guess you are referring to draft-ietf-mobileip-hmipv6-00? >I think it has nothing to do with a marketing draft so I wonder what >you are referring to specifically. It is authored by people employed >by Ericsson and INRIA who have already an implementation. Since, as >I seem to understand, we are not here representing or advertising >companies I also don't think your statement on Ericsson is relevant. >But I do agree with the "it is wonderful" bit! > just curious, what is the invention here? >> Similarly, if a mobile access helper anycast address existed, >> the local >> router could either be that system, or could tunnel messages to it. If >> could advise the mobile device of its presence and >> willingness to act as a >> care-of address; the mobile node would give this mobile >> access point a more >> local care-of address, and said MAP would forward messages >> directed to it >> to that more local COA. The only concern I have with putting the COA >> directly on the mobile device is the need for someone to forward them >> during handoffs, and this would allow for that. It seems like >> this "helper" >> model is not dissimilar to the Hierarchical Mobility model, >> but simpler. The reason you pointed out about CoA's is one of the reasons, the draft-dommety-mobileip-ipv6-lma-01.txt leaves option for using the helpers CoA. -Gopal From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 18:28: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 SAA21997 for ; Tue, 17 Oct 2000 18:28:23 -0400 (EDT) Received: from standards (47.234.32.16:3640) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6003@standards.nortelnetworks.com>; Tue, 17 Oct 2000 18:11:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23463 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 18:11:26 -0400 Received: from sj-msg-core-2.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6001@standards.nortelnetworks.com>; Tue, 17 Oct 2000 18:11:26 -0400 Received: from p7020-img-nt.cisco.com ([64.104.42.111]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA06688; Tue, 17 Oct 2000 15:26:20 -0700 (PDT) X-Sender: fred@flipper X-Mailer: QUALCOMM Windows Eudora Version 5.0 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.0.0.25.2.20001018071232.03508eb0@flipper> Date: Wed, 18 Oct 2000 07:16:12 -0700 Reply-To: Fred Baker Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Fred Baker Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: "Hesham Soliman (EPA)" X-cc: ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A50C613C93@eaubrnt018.epa.er icsson.se> At 08:36 PM 10/17/00 +1100, Hesham Soliman (EPA) wrote: >=> I'm not sure if I understand what you mean by the foreign agent. >Perhaps you have another entity in mind ? Because the current MIPv6 draft >does not have foreign agents. And therefore doesn't have a soft hand off option unless one can literally talk with both routers during the hand off. The Hierarchical Mobility draft suggests having an external system offer one of its addresses a second care-of address to provide this; to me, that's a foreign agent in disguise, and would be useful in that case. Sorry I was quick on the language. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 18:37: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 SAA22099 for ; Tue, 17 Oct 2000 18:37:39 -0400 (EDT) Received: from standards (47.234.32.16:3640) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6055@standards.nortelnetworks.com>; Tue, 17 Oct 2000 18:20:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23456 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 18:20:42 -0400 Received: from shannon.klte.hu (shannon.math.klte.hu) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5FFB@standards.nortelnetworks.com>; Tue, 17 Oct 2000 18:10:41 -0400 Received: from localhost by shannon.klte.hu (SMI-8.6/SMI-SVR4) id WAA17471; Tue, 17 Oct 2000 22:04:54 -0100 Content-Type: text/plain X-Accept-Language: en MessageID: <3vxpmoy42zfgrv4.171020001522@localhost> Message-ID: <200010172304.WAA17471@shannon.klte.hu> Date: Tue, 17 Oct 2000 18:20:42 -0400 Reply-To: maildirect@POSTMASTER.CO.UK Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: maildirect@POSTMASTER.CO.UK Subject: [MOBILE-IP] it's your future... X-To: mlithwik@ssss.gouv.qc.ca To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Multiply Your Income... Seeking positive and motivated individuals that are serious about creating 6-7 figure wealth. Do you have a burning desire to enhance the quality of your existing life? Would you like to live the life that others only dream about? The fact is we have many people in this enterprise that earn from 10K to 50k per month from the privacy of their own home and are achieving financial independence in 2-3 years obviously wealthy and having total freedom both personal and financial. If you think this is too good to be true or are skeptical then this may not be for you... Many have been conditioned to believe it must be illegal, immoral or unethical to ever earn any real profits from our efforts. This is all about Education and Knowledge that was once reserved for the ultra wealthy and the well connected. By calling the phone number below you will hear about a powerful Wealth Building Educational Program and a brilliant marketing concept. How would you like to: 1. Drastically reduce personal, business and capital gains taxes? 2. Protect all assets from any form of seizure, liens, or judgments? 3. Create a six-figure income every 4 months? How about: 1. Restoring and preserving complete personal and financial privacy? 2. Create and amass personal wealth, multiply it and protect it? 3. Realize a 3 to 6 times greater returns on your money? 4. Legally make yourself and your assets completely judgment-proof, seizure-proof, lien-proof, divorce-proof, attorney-proof, IRS-proof, and become completely insulated? Are you a BIG thinker, BIG dreamer and a person that believes they deserve to have the best in life? Are you capable of recognizing that once in a lifetime opportunity when it's looking right at you? Countless others have missed their shot at the title only to look back years later and wished they should've because they could've. If you have Moderate People Skills, a Strong Work Ethic, and a Burning Desire to become Financially Independent in the next 2-3 years then I invite you to take a tour of the turnkey information system. There are 3 steps in the process: 1st step: 1"888"269"5535 3-minute intro (24 hr toll free) 2nd step: Leave your name and phone number requesting a informational interview 3rd step: Receive a detailed overview of the product and marketing plan This is about money, freedom, and financial independence. It is unlike any other business and it is NOT MLM Take the time to gather the information...It is truly remarkable!!! The most effective WAY TO BE REMOVED FROM FUTURE MAILINGS IS TO REPLY TO THE FOLLOWING LINK mailto:removeme@greysuitandtie.net?subject=REMOVE ########################################################## Notice, incidentally, that this selectionally introduced contextual feature necessitates that coagulative measures be applied to any normative concept of the linguistic/holistic continuum. To characterize a linguistic level L, a primary interrelationship of system and/or subsystem logistics recognizes the importance of other disciplines, while taking into account Propp's basic formulation. Further, the characterization of specific criteria can be defined in such a way as to impose the management-by-contention principle. As a resultant implication, the characterization of critically co-optive criteria maximizes the probability of project success, while minimizing cross-cultural shock elements in Krapp's Last Tape. It should be noted that the natural general principle that will subsume this case is not quite equivalent to the ultimate standard that determines the accuracy of any proposed grammar. In summary, any exponential Folklife coefficient requires considerable systems analysis and trade-off studies to arrive at the extended C-command discussed in connection with (34). Of course, a further and associated contradictory element adds overriding performance constraints to a corpus of utterance tokens upon which conformity has been defined by the paired utterance test. For example, the interrelation of system and/or subsystem technologies is to be regarded as the traditional practice of grammarians. eriace, incidentally, that the characterization of critically co-optive criteria effects a significant implementation of our hedonic Folklife perspective over a given time period. ########################################################## From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 23:28: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 XAA27911 for ; Tue, 17 Oct 2000 23:28:17 -0400 (EDT) Received: from standards (47.234.32.16:3418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA61FB@standards.nortelnetworks.com>; Tue, 17 Oct 2000 23:11:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24128 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 23:11:24 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:38096) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA61F9@standards.nortelnetworks.com>; Tue, 17 Oct 2000 23:11:23 -0400 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 NAA05775; Wed, 18 Oct 2000 13:22:51 +1000 (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 OAA25557; Wed, 18 Oct 2000 14:25:15 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id <4XFQS0A3>; Wed, 18 Oct 2000 14:25:25 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613C98@eaubrnt018.epa.ericsson.se> Date: Wed, 18 Oct 2000 14:25:23 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] MIPv6 node location detection X-cc: ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > At 08:36 PM 10/17/00 +1100, Hesham Soliman (EPA) wrote: > >=> I'm not sure if I understand what you mean by the foreign agent. > >Perhaps you have another entity in mind ? Because the current MIPv6 > draft > >does not have foreign agents. > And therefore doesn't have a soft hand off option unless one can literally > > talk with both routers during the hand off. > => As far as I'm aware the term "soft handoff" is related to certain radio technologies that allow data to be received from multiple access points. This in no way implies receiving two separate traffic streams. It is an L2 feature that is used for handoffs and also as a mechanism for improving the received signal quality. IMO having foreign agents is not relevant for achieving soft handoffs. In fact the soft handoffs concept (as used today) is completely transparent to MIP (v4 and v6) or any L3 function as it happens on L2. > The Hierarchical Mobility draft > suggests having an external system offer one of its addresses a second > care-of address to provide this; to me, that's a foreign agent in > disguise, > and would be useful in that case. Sorry I was quick on the language. > => No problems. I obviously agree with comment on the usefulness of the MAP function. We avoided using the term FA in the draft because it is associated with the current understanding of FAs in IPv4. There certainly are differences. - FAs are mandatory on each link in MIPv4. MAPs are not. - FAs in MIPv4 perform other tasks like authentication which is a AAA function and need not be tied to mobility functions. - A MN can choose MAPs in the hierarchy based on various information in the MAP option. You can't do that with FAs. - MAPs can exist on any level of a hierarchy including first hop routers and are completely independant from each other. You can probably see more differences in the draft. What we tried to do is go away from the FA concept because we don't believe FAs ( as introduced in V4) are needed in IPv6. Perhaps some of the functions in FAs can be useful. But it seems unnecessary to copy and paste the functionality into IPv6. Hesham From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 18 05:51: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 FAA14207 for ; Wed, 18 Oct 2000 05:51:16 -0400 (EDT) Received: from standards (47.234.32.16:1437) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA63EF@standards.nortelnetworks.com>; Wed, 18 Oct 2000 5:34:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24790 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 05:34:04 -0400 Received: from smtp1.chello.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA63EB@standards.nortelnetworks.com>; Wed, 18 Oct 2000 5:24:03 -0400 Received: from xelthomasek01 ([212.209.134.2]) by smtp1.chello.se (InterMail vK.4.02.00.00 201-232-116 license 13ed6d939a101f33a28aa8ad6d2fac65) with SMTP id <20001018093840.ICQA28958.smtp1@xelthomasek01>; Wed, 18 Oct 2000 11:38:40 +0200 References: <200010171415.QAA73291@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <002e01c038e6$96cc9f80$6309000a@xelthomasek01> Date: Wed, 18 Oct 2000 11:34:18 +0200 Reply-To: Thomas Eklund Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Thomas Eklund Organization: Home Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: Francis Dupont , "John F. Leser" X-cc: ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi some commente regarding the movement detection algorithm. I agree that it might not be a good idea to tie your movement detection to when you are seeing an advertisement from a router with a different prefix. First of all - the statemachine for the movementdetection can be at two places - either in the 1) mobile node (which is the case today) or 2) it can sit in the network and then you could have network controlled handoff. To improve handoff you must make increase mobile IP's link-layer awarness. This is usually achived by listening on the field strengh or something similar of the radio link. The solution is different for every different radio link you have. Take 802.11 ethernet for instance, there you can associate every radio cell (and AP) to an IP subnet with a new prefix or you can associate several AP to an IP subnet (recomended). In case 1) you can associate every radio cell with a subnetprefix and you modify you movement detection algoritm (MDA) so that it builds up an internal list with prefixes and subnet and associated field strengh. For instance: General Parameters: Joning treshsholds: xxx dBm Leaving Treshholds: xxx dBm CoA Current Subnet Field strengh Active CoA CoA1 Prefix 1 xx dBm --- CoA2 Prefix 2 xx dBm Active CoA3 Prefix 3 xx dBm --- CoA4 Prefix 4 xx dBm --- CoA5 Prefix 5 xx dBm --- The intention is also to start bulding new CoA before you must switch over to a new AP which will make you handover quicker. You listens on the field strengh of the different radio cells or subnets and associate make you handover based on the field strengh. This approach could also be done from the AP or BS which would be a good aproach o a WAN radio like GSM or CDMA. Then the movement detection algorithm sits (it is not called that in GSM terms) in a BSC and in tells you to do you handover but in this case you would have to interupt that let mobile IP have that info and then mobile IP could be invoked in network initiated handoffs. This is nice on paper and would really optimize the radio network for IP but there is a lot of polotics here which can make it very difficult. You can also include QoS parameter in your handover design and you can make it very advanced. In other it is nothing in the spec that stops you from achieving very good handoffs. -- Thomas Eklund ----- Original Message ----- From: "Francis Dupont" To: "John F. Leser" Cc: ; Sent: Tuesday, October 17, 2000 4:15 PM Subject: Re: [MOBILE-IP] MIPv6 node location detection > In your previous mail you wrote: > > Reading through section 10.4 of the MIPv6 draft (version 12), I get the > impression that: > > 1. Movement detection is not a simple problem to solve. The draft > doesn't really specifiy what method should be used. > > => there are many different methods, some of them are (too) slow, > some of them can detect movements when there is no movement, this can > be a problem or not... I think we need to get results from fast/smart/... > handoff special group and from implemention experiences. > > 2. Seeing an adverisement from a router with a different prefix is not a > good way to detect movement. > > => I agree but the other way is not better. > > The preferred movement detection method seems to be loss of > reachability of the MN's default router, > > => this is not good if there are more than one router and of course > is very bad if the number of potential default routers is large enough... > > which is noticed through neighbor unreachability detection > > => which uses neighbor solicitations, not router solicitations ! > > and/or use of the router advertisement interval option. > > => this point should be added into neighbor discovery specs (ie. > it is useful in general, not only for mobility). > > > > I also can't find RFC or draft which define exactly address list in a > > > MIPv6 MN. A IPv6 node have a address list and every prefix has lifetime > > => in *theory* the list is the union of local prefixes and home prefixes, > both are in router advertisements on the local link and through the tunnel > with the home agent with the according lifetimes. In order to get the whole > list ASAP someone suggested in this list that the home agent sends router > advertisements to the MN when a home registration is done. > > 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)... > > An open question is what to do with DHCPv6? > > Regards > > Francis.Dupont@enst-bretagne.fr > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 18 13: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 NAA03867 for ; Wed, 18 Oct 2000 13:26:13 -0400 (EDT) Received: from standards (47.234.32.16:4779) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA66CE@standards.nortelnetworks.com>; Wed, 18 Oct 2000 10:54:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25719 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 10:54:10 -0400 Received: from iol.unh.edu (mars.iol.unh.edu) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA66CC@standards.nortelnetworks.com>; Wed, 18 Oct 2000 10:54:09 -0400 Received: from localhost (jfl@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id LAA26480; Wed, 18 Oct 2000 11:10:50 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Wed, 18 Oct 2000 11:10:50 -0400 Reply-To: "John F. Leser" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "John F. Leser" Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: Thomas Eklund X-cc: Francis Dupont , ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <002e01c038e6$96cc9f80$6309000a@xelthomasek01> On Wed, 18 Oct 2000, Thomas Eklund wrote: > Hi some commente regarding the movement detection algorithm. > I agree that it might not be a good idea to tie your movement detection to > when you are seeing an advertisement from a router with a different prefix. > > First of all - the statemachine for the movementdetection can be at two > places - either in the 1) mobile node (which is the case today) or 2) it can > sit in the network and then you could have network controlled handoff. > > To improve handoff you must make increase mobile IP's link-layer awarness. > This is usually achived by listening on the field strengh or something > similar of the radio link. The solution is different for every different > radio link you have. [cut] I don't doubt that there are many ways the link layer could provide excellent movement detection. I think the issue here is how to provide some movement detection for MIPv6 without any special signalling from lower layers. I think you did touch on an important point - movement detection is really two problems - (1) detecting movement on to a link, and (2) detecting movement off of a link. If the mobile node is eager to move to new networks, then it is only critial that (1) take place quickly for smooth handoffs. Its somewhat less clear to me when (2) must take place, but it should happen eventually. With this in mind, I'd like to suggest this as an idea for movement detection: - Require that a home agent's router advertisements always contain all of the prefixes on the network that are valid for home or CO addresses. - Then, whenever a MN receives an RA with the H bit set, it will know with certainty whether that RA came from the current home or foreign network, or from some new network, based on whether the prefix of the MN's home or current CO address is advertised in the RA. This way, movement onto a new link is detected as soon as any home agent on that link sends an advertisement. - Whenever an RA is received indicating movement onto a new link, the MN transitions neigbor cache entry for the old default router(s) to stale, to accelerate unreachability detection. Of course, the danger here is that the network could be misconfigured so that home agents are not advertising all prefixes. This would be sub-optimal (mobility would be uses when it is not needed), but wouldn't prevent the mobile node from communicating. I'm curious what people think of this. ------------------------------------------------------------------- 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 Wed Oct 18 13:26: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 NAA03874 for ; Wed, 18 Oct 2000 13:26:14 -0400 (EDT) Received: from standards (47.234.32.16:4779) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA673F@standards.nortelnetworks.com>; Wed, 18 Oct 2000 11:24:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25869 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 11:24:26 -0400 Received: from mailhost.iprg.nokia.com (205.226.5.12:64405) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA673D@standards.nortelnetworks.com>; Wed, 18 Oct 2000 11:24:23 -0400 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 IAA21610; Wed, 18 Oct 2000 08:39:33 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9IFdU131803; Wed, 18 Oct 2000 08:39:30 -0700 X-Virus-Scanned: Wed, 18 Oct 2000 08:39:30 -0700 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) smtpdbu9Lwg; Wed, 18 Oct 2000 08:39:26 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39EDC431.856465D2@iprg.nokia.com> Date: Wed, 18 Oct 2000 08:39:29 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: "John F. Leser" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello John, I've been unable to keep up with the general discussion on this issue, but I've scanned through many of the messages. I think this is an issue that should be resolved in the next (and perhaps _last_ before Proposed Standard) revision of the Mobile IPv6 protocol specification, which is coming imminently. Thus, I'd like to find out if we can get to some agreement on whatever clarifications or enhancements are needed. > I don't doubt that there are many ways the link layer could provide > excellent movement detection. I think the issue here is how to provide > some movement detection for MIPv6 without any special signalling from > lower layers. Agree. Your suggestion: > - Require that a home agent's router advertisements always contain all > of the prefixes on the network that are valid for home or CO addresses. seems to solve the problem with least harm. I particularly think it compares well with another alternative which was suggested, according to which the mobile node would have to assume that every advertising home agent was its own home agent. I think the strategy above will introduce less traffic on the wireless link. I also agree with previous statements that renumbering should happen gently. In the context of your suggestion, this would mean that the deprecated prefix would be carried by agent advertisements for quite a while. I think that whatever is specified in the Neighbor Discovery draft SHOULD cover the required time durations for deprecated addresses, but I didn't go check the wording before sending this message. If it is not sufficient there, then we should make some explicit parameter value specifications in the Mobile IPv6 draft. > - Whenever an RA is received indicating movement onto a new link, > the MN transitions neigbor cache entry for the old default router(s) to > stale, to accelerate unreachability detection. Agree. And, if your strategy is adopted, I reckon the draft should explicitly state this. > Of course, the danger here is that the network could be misconfigured so > that home agents are not advertising all prefixes. This would be > sub-optimal (mobility would be uses when it is not needed), but wouldn't > prevent the mobile node from communicating. A lot of things can go wrong if the network is misconfigured! Maybe we can put mandatory requirements in the draft so that such misconfigurations go against explicitly stated MUSTs. Your help in determining some correct wording would be appreciated. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 18 14:18: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 OAA10338 for ; Wed, 18 Oct 2000 14:18:11 -0400 (EDT) Received: from standards (47.234.32.16:3701) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6884@standards.nortelnetworks.com>; Wed, 18 Oct 2000 14:00:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26305 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 14:00:54 -0400 Received: from mgw-x3.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6882@standards.nortelnetworks.com>; Wed, 18 Oct 2000 14:00:53 -0400 Received: from esebh01nok.ntc.nokia.com (esebh01nok.ntc.nokia.com [131.228.118.150]) by mgw-x3.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e9IIG3B17037 for ; Wed, 18 Oct 2000 21:16:03 +0300 (EET DST) Received: by esebh01nok with Internet Mail Service (5.5.2652.78) id ; Wed, 18 Oct 2000 21:16:03 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <01D91AFB08B6D211BFD00008C7EABAE105855C93@eseis04nok> Date: Wed, 18 Oct 2000 21:16:02 +0300 Reply-To: jarno.rajahalme@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jarno Rajahalme Subject: Re: [MOBILE-IP] MIPv6 node location detection To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM John F. Leser wrote: > - Then, whenever a MN receives an RA with the H bit set, it will know > with certainty whether that RA came from the current home or foreign > network, or from some new network, based on whether the prefix of the > MN's home or current CO address is advertised in the RA. This way, > movement onto a new link is detected as soon as any home agent on that > link sends an advertisement. > What if the MN never receives a RA with the H bit set? I hope you do not assume all links have home agents. With regards, Jarno Rajahalme From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 18 15:01: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 PAA17079 for ; Wed, 18 Oct 2000 15:01:38 -0400 (EDT) Received: from standards (47.234.32.16:3701) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA691F@standards.nortelnetworks.com>; Wed, 18 Oct 2000 14:44:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26501 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 14:44:34 -0400 Received: from iol.unh.edu (mars.iol.unh.edu) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA691D@standards.nortelnetworks.com>; Wed, 18 Oct 2000 14:44:34 -0400 Received: from localhost (jfl@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id PAA02212; Wed, 18 Oct 2000 15:00:50 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Wed, 18 Oct 2000 15:00:50 -0400 Reply-To: "John F. Leser" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "John F. Leser" Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: Jarno Rajahalme To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE105855C93@eseis04nok> On Wed, 18 Oct 2000, Jarno Rajahalme wrote: > John F. Leser wrote: > > - Then, whenever a MN receives an RA with the H bit set, it will know > > with certainty whether that RA came from the current home or foreign > > network, or from some new network, based on whether the prefix of the > > MN's home or current CO address is advertised in the RA. This way, > > movement onto a new link is detected as soon as any home agent on that > > link sends an advertisement. > > > > What if the MN never receives a RA with the H bit set? Then the mobile node falls back on some slower mode of movement detection. > I hope you do not assume all links have home agents. > Routers could be configured to fill this role while not accepting home registrations by setting the H bit and inclunding a home agent information option with 0 home agent lifetime (This is currently against spec, but could be defined to mean 'I have complete prefix information but will not serve as a home agent') Or, perhapse it would be better/cleaner to define another bit the RA to indicate that this router has the complete prefix list. > With regards, > > Jarno Rajahalme > ------------------------------------------------------------------- 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 Wed Oct 18 18:10: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 SAA09756 for ; Wed, 18 Oct 2000 18:10:47 -0400 (EDT) Received: from standards (47.234.32.16:3078) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6A25@standards.nortelnetworks.com>; Wed, 18 Oct 2000 17:53:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26826 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 17:53:44 -0400 Received: from www.gbtc.org by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6A20@standards.nortelnetworks.com>; Wed, 18 Oct 2000 17:43:44 -0400 Received: by www.gbtc.org id AA05785; Wed, 18 Oct 2000 17:58:09 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Message-ID: <200010182158.AA05785@www.gbtc.org> Date: Wed, 18 Oct 2000 17:58:09 -0400 Reply-To: frank65_8@NORCOL.AC.UK Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: frank65_8@NORCOL.AC.UK Subject: [MOBILE-IP] Hi, this is for you..... To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Dear Friend: Do you need a change in your life? Do you remember when the entire world seemed like it was yours for the taking? Do you remember a time when all of your hopes and dreams seemed like they were attainable? First of all, let's be honest. You are not going to earn $50,000 in 20 days. It just isn't going to happen. Anyone who tells you that you can, is not being truthful. But, let me tell you about a plan that can possibly make all your dreams come true...keep reading! ******************************************************************** I would like to tell you about a plan that has changed my life. Take a calculator and figure in the worst possible scenario. Decide for yourself. If you decide that you want to take control of your life and move forward...that is your decision. ******************************************************************** Here's the step by step plan summary. 1)You order the 4 reports listed below ($5 each). They come to you by email. 2)Save a copy of this entire letter and put your name at report #1. Move all other names down. (You will be removing the person at the level 4) 3)Use any of the hundreds of bulk email services out there. 4)Orders will come right to your door. Simply email them the report they ordered.Isn't that about as easy as it gets??? ******************************************************************** Your cost to participate in this program is practically nothing (surely you can afford $20 and initial bulk mailing cost). You obviously already have a computer and an Internet connection and e-mail is FREE! The primary method of building your downline is bulk email. Let's say that you decide to start small, just to see how it goes. Let's assume that you and all those involved email out only 2,000 programs each. Let's also assume that the mailing receives a 0.5% response. The response could be much better. Also, many people will email out more than 2,000 programs. With a 0.5% response, that is only 10 orders for Report #1. Those 10 respond by sending out 2,000 programs each for a total of 20,000. Out of those 0.5%, 100 people respond and order 20,000. The 0.5% response rate to that is 1,000 orders for Report #3. Those 1,000 send out 2,000 each for a total of 2,000,000. The 0.5% response rate is 10,000 orders for report #4. That is 10,000 $5 bills for you. CASH!!! ********************************************************************* Your total income in this example is: $50+ $500+ $5000+ $50,000 for a total of $55,550!!! ********************************************************************* REMEMBER FRIEND. THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM!!! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR EVEN HALF MAILED OUT 100,000 INSTEAD OF 2,000. Believe, most people will do just that, and more!!! Friend, you do the math. You look at the opportunity, if you decide that you would like to participate in this program, the decision is yours. Recently, the Federal Trade Commission has tried to stop chain letters which promise you will make tons of money by participating. Such chain letters are NOT legal because of this reason. This new program complies with all the rules. To be legal, a chain letter must offer a product and must not promise you will get rich by taking part. If you look at the program, do the math and decide that you will make money, it is your opinion. No such claim is here. However, I do strongly encourage you to do the calculations. Figure out the worst possible response and see how it calculates. Your orders come right to your door and you send your reports via email. You are not involved in personal selling. You do it privately in your own home, store, or office. This is the EASIEST plan anywhere. It is simply order filling by email. Order the four reports shown on the list below. You can't sell them if you don't order them!!!. For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR EMAIL ADDRESS, and YOUR NAME AND RETURN ADDRESS (in case there's a problem). MAKE SURE YOUR RETURN ADDRESS IS ON THE ENVELOPE IN CASE OF ANY MAIL PROBLEMS! Report #1 will tell you how to download bulk email software and email addresses so you can send it out to thousands while you sleep. Remember that 50,000+ new people are joining the Internet every month. By the way, there are over 50 million email addresses with millions more joining the Internet each year, so we don't worry about "saturation". People are used to seeing and hearing the same advertisements every day on radio/TV. How often have you received the same pizza flyers on your door. Then, one day you are hungry for pizza and immediately recall the flyer. Same thing with this letter. I received this letter many times- then one day I decided it was time to try it. This program will not require you to come into contact with people or take any telephone calls. Just follow the instructions. There is no guarantee either stated or implied that anyone participating in this program will earn $50,000+. (You must include that statement to make this legal.) ******* TIPS FOR SUCCESS ******* TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. -- Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/report. It is required for this to be a legal business and they need the reports to send out their letters (with your name on them!) -- ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. -- Be patient and persistent with this program. ********************************************************************** Get started TODAY!! Notes- ALWAYS SEND $5 CASH (US CURRENCY) FOR EACH REPORT. CHECKS NOT ACCEPTED. make sure the cash is concealed by wrapping it in two sheets of paper. On one of those sheets write: (a) the number and name of the report you are ordering, (b) your e-mail address, and (c) your name and postal address. REPORT #1 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #1 FROM: S. STARK P.O. BOX 61009 HOUSTON, TEXAS 77208-1009 REPORT #2 "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #2 FROM: WAYNE ELLIOTT 11918 SE DIVISION #358 PORTLAND, OR 97266 REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: RYAN ROMNEY P.O. BOX 540421 NORTH SALT LAKE, UT 84054-0421 REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: RUSSELL OLSEN 5409 YARMOUTH AVE #3 ENCINO, CA 91316 ******************************************************************** This ad is being sent in compliance with Senate Bill 1618, Title 3, section 301, paragraph (a)(2)(C). Further transmissions to you by the sender of this e-mail may be stopped at no cost to you by sending a reply to this e-mail address with the words "remove" in the subject line. ******************************************************************** From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 18 18:39: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 SAA12916 for ; Wed, 18 Oct 2000 18:39:47 -0400 (EDT) Received: from standards (47.234.32.16:3078) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6AAD@standards.nortelnetworks.com>; Wed, 18 Oct 2000 18:22:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26963 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 18:22:25 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6A87@standards.nortelnetworks.com>; Wed, 18 Oct 2000 18:12:24 -0400 Received: from purol.East.Sun.COM ([129.148.9.11]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA00686; Wed, 18 Oct 2000 15:27:30 -0700 (PDT) Received: from onion.east.sun.com (onion [129.148.174.110]) by purol.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id SAA03199; Wed, 18 Oct 2000 18:27:28 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Wed, 18 Oct 2000 18:27:20 -0400 Reply-To: Steven Glass - Solaris Software Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Steven Glass - Solaris Software Subject: Re: [MOBILE-IP] Hi, this is for you..... X-cc: Phil Roberts , Basavaraj Patil To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <200010182158.AA05785@www.gbtc.org> >Dear Friend: > >Do you need a change in your life? Yes. Any update on the WG's ability to get rid of this stuff? Cheers, Steve From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 18 18:46: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 SAA13670 for ; Wed, 18 Oct 2000 18:46:17 -0400 (EDT) Received: from standards (47.234.32.16:3078) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6AEF@standards.nortelnetworks.com>; Wed, 18 Oct 2000 18:28:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27100 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 18:28:14 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6AED@standards.nortelnetworks.com>; Wed, 18 Oct 2000 18:28:13 -0400 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA12885 for ; Wed, 18 Oct 2000 16:43:24 -0600 (MDT) 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 PAA21801; Wed, 18 Oct 2000 15:43:23 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA05933; Wed, 18 Oct 2000 15:43:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Wed, 18 Oct 2000 15:41:02 -0700 Reply-To: Patrice Calhoun Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] Hi, this is for you..... X-To: Steven Glass - Solaris Software To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" > >Dear Friend: > > > >Do you need a change in your life? > > Yes. Any update on the WG's ability to get rid of this stuff? > I don't think this was unsolicited spam, Steve. As it turns out, I believe the author of the e-mail correctly assumed that most people on this list need a life. :) PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 18 18:53: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 SAA14468 for ; Wed, 18 Oct 2000 18:53:21 -0400 (EDT) Received: from standards (47.234.32.16:3078) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6B5B@standards.nortelnetworks.com>; Wed, 18 Oct 2000 18:36:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27242 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 18:36:17 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:54821) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6B59@standards.nortelnetworks.com>; Wed, 18 Oct 2000 18:36:16 -0400 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 IAA21455 for ; Thu, 19 Oct 2000 08:48:31 +1000 (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 JAA22018 for ; Thu, 19 Oct 2000 09:50:56 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id <4XFQTPV2>; Thu, 19 Oct 2000 09:51:07 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613CBB@eaubrnt018.epa.ericsson.se> Date: Thu, 19 Oct 2000 09:51:05 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] MIPv6 node location detection To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > On Wed, 18 Oct 2000, Jarno Rajahalme wrote: > > > John F. Leser wrote: > > > - Then, whenever a MN receives an RA with the H bit set, it will know > > > with certainty whether that RA came from the current home or foreign > > > network, or from some new network, based on whether the prefix of the > > > MN's home or current CO address is advertised in the RA. This way, > > > movement onto a new link is detected as soon as any home agent on that > > > link sends an advertisement. > > > > > > > What if the MN never receives a RA with the H bit set? > > Then the mobile node falls back on some slower mode of movement > detection. > => I'm not sure why you're emphasising the 'H' bit. The H bit is only a flag that means "I'm a HA". It does NOT mean "I'm YOUR HA". So having said that, I would say you don't have to worry about having the HA tell if you're at home or not. You know that from the RA, whether it comes from your HA or another router. > > I hope you do not assume all links have home agents. > > > Routers could be configured to fill this role while not accepting home > registrations by setting the H bit and inclunding a home agent information > option with 0 home agent lifetime (This is currently against spec, but > could be defined to mean 'I have complete prefix information but will not > serve as a home agent') Or, perhapse it would be better/cleaner to define > another bit the RA to indicate that this router has the complete prefix > list. > => Why not just advertise the RA ? What is the point of the H bit ? I'd like to repeat a comment that was said before. A MN does not have to move when it has a new prefix. It has to move when it hears a new prefix and the old default router disappears. If you think that it is too slow to probe the old router then you can move as soon as you hear a new prefix. This is ok as long as you don't oscillate. Hesham From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 18 19: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 TAA16062 for ; Wed, 18 Oct 2000 19:08:05 -0400 (EDT) Received: from standards (47.234.32.16:3078) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6BB1@standards.nortelnetworks.com>; Wed, 18 Oct 2000 18:51:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27359 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 18:51:07 -0400 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6BAF@standards.nortelnetworks.com>; Wed, 18 Oct 2000 18:51:06 -0400 Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e9IN6GP26113 for ; Thu, 19 Oct 2000 02:06:16 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id <483HLRK5>; Wed, 18 Oct 2000 18:02:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B01A6E45B@daeis07nok> Date: Wed, 18 Oct 2000 18:02:42 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] Hi, this is for you..... To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Yes. Dave Oran has authorized us to go ahead and put in place mechanisms within the guidelines. I have requested the list owner (Ron Young - ronyoung@nortelnetworks.com) to at the least have e-mails to the list sent only by people who are registered. I still need to check if that is allowed in the guidelines. Maybe you can shed some light on this Steve and let me know or Ron know what are the things within the guidelines. -Basavaraj > -----Original Message----- > From: EXT Steven Glass - Solaris Software > [mailto:Steven.Glass@east.sun.com] > Sent: Wednesday, October 18, 2000 5:27 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Cc: Phil Roberts; Basavaraj Patil > Subject: Re: [MOBILE-IP] Hi, this is for you..... > > > >Dear Friend: > > > >Do you need a change in your life? > > Yes. Any update on the WG's ability to get rid of this stuff? > > Cheers, > Steve > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 18 22:16: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 WAA07662 for ; Wed, 18 Oct 2000 22:16:37 -0400 (EDT) Received: from standards (47.234.32.16:3825) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6C8C@standards.nortelnetworks.com>; Wed, 18 Oct 2000 21:59:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27625 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 21:59:17 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6C8A@standards.nortelnetworks.com>; Wed, 18 Oct 2000 21:59:17 -0400 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 TAA14000 for ; Wed, 18 Oct 2000 19:14:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9J2EPs13545 for ; Wed, 18 Oct 2000 19:14:25 -0700 X-Virus-Scanned: Wed, 18 Oct 2000 19:14:25 -0700 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) smtpdpKROcg; Wed, 18 Oct 2000 19:14:21 PDT X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4B6BC00CD15FD2119E5F0008C7A419A50C613CBB@eaubrnt018.epa.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39EE58A9.8B73462C@iprg.nokia.com> Date: Wed, 18 Oct 2000 19:12:57 -0700 Reply-To: Charlie Perkins Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Charlie Perkins Organization: Nokia Subject: Re: [MOBILE-IP] MIPv6 node location detection To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, I thought that the idea was to have the home agent advertise all of the "available" prefixes. If the mobile node is on a link that doesn't have a home agent, then it should still be able to listen for regular advertisements, but then it doesn't have to worry about renumbering its home address. Whatever strategy is realistic for renumbering non-mobile nodes, will also work for mobile nodes and their care-of addresses. I don't think there is any problem here. I thought that the only problem was when the mobile node might have been away from home for long enough to miss out on some transitional advertisements from its home agent. Is there something else? Regards, Charlie P. "Hesham Soliman (EPA)" wrote: > > On Wed, 18 Oct 2000, Jarno Rajahalme wrote: > > > > > John F. Leser wrote: > > > > - Then, whenever a MN receives an RA with the H bit set, it will know > > > > with certainty whether that RA came from the current home or foreign > > > > network, or from some new network, based on whether the prefix of the > > > > MN's home or current CO address is advertised in the RA. This way, > > > > movement onto a new link is detected as soon as any home agent on that > > > > link sends an advertisement. > > > > > > > > > > What if the MN never receives a RA with the H bit set? > > > > Then the mobile node falls back on some slower mode of movement > > detection. > > > => I'm not sure why you're emphasising the 'H' bit. > The H bit is only a flag that means "I'm a HA". > It does NOT mean "I'm YOUR HA". So having said that, > I would say you don't have to worry about having the HA > tell if you're at home or not. You know that from the RA, > whether it comes from your HA or another router. > > > > I hope you do not assume all links have home agents. > > > > > Routers could be configured to fill this role while not accepting home > > registrations by setting the H bit and inclunding a home agent information > > option with 0 home agent lifetime (This is currently against spec, but > > could be defined to mean 'I have complete prefix information but will not > > serve as a home agent') Or, perhapse it would be better/cleaner to define > > another bit the RA to indicate that this router has the complete prefix > > list. > > > => Why not just advertise the RA ? What is the point > of the H bit ? > > I'd like to repeat a comment that was said before. > A MN does not have to move when it has a new > prefix. It has to move when it hears a new prefix > and the old default router disappears. > > If you think that it is too slow to probe the old router > then you can move as soon as you hear a new prefix. > This is ok as long as you don't oscillate. > > Hesham From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 17:47: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 RAA14004 for ; Thu, 19 Oct 2000 17:47:01 -0400 (EDT) Received: from standards (47.234.32.16:4720) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA77D3@standards.nortelnetworks.com>; Thu, 19 Oct 2000 17:29:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31192 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 17:29:45 -0400 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA77CD@standards.nortelnetworks.com>; Thu, 19 Oct 2000 17:19:40 -0400 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA08835 for ; Thu, 19 Oct 2000 14:34:23 -0700 (MST)] Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA14369 for ; Thu, 19 Oct 2000 14:33:43 -0700 (MST)] Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2651.58) id <429QHBSB>; Thu, 19 Oct 2000 16:33:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A0498FB95@il27exm02.cig.mot.com> Date: Thu, 19 Oct 2000 16:33:05 -0500 Reply-To: Nakhjiri Madjid-MNAKHJI1 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Nakhjiri Madjid-MNAKHJI1 Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: "John F. Leser" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I am new to this list and MIP in general and v6 in particular, so I am sorry if there has been a thread about this in the past. A pointer to a place to read is fine with me too. My question concerns the security of this scenario: The home link changes it's prefix and starts sending router advertisement messages, we are trying to find a solution by which the mobile need to recognize that it has not moved and it is just its old Home link with a new address. What if we all of a sudden had a malicious attacker, who starts sending router advertisement with bogus new home addresses(assuming it has brought the home router down through some DoS attack in the mean time) and pretending to be the home router. As far as I understand the router advertisements are not authenticated. Wouldn't all the mobile nodes getting services in that area be confused for a while. Is there a restriction on who can send RAs? Does there have to be some kind of security association that need to be established before somebody can send a router advertisement? I guess if we choose to send info on both the old and the new address in the advertisement it helps, but I do not how much? Thanks, Madjid Nakhjiri -----Original Message----- From: John F. Leser [mailto:jfl@IOL.UNH.EDU] Sent: Friday, October 13, 2000 9:14 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] MIPv6 node location detection On Sat, 14 Oct 2000, Hesham Soliman (EPA) wrote: > > What is the difference between two advertisement below ? > > - Renumbered home link router advertisement > > - Router advertisement in a foreign link > > > > My question is why the mobile node don't just add the new address > > in MN's address list. How do the MN decide whether it start MIPv6 > > process or autoconfiguration process for renumbered home link address. > > What if the all home addresses in the list have expired before the MN > > get FA's router advertisement, can the MN still use the expired address > > record > > in it's system ? > > > => I think you're certainly asking the right question but > perhaps to the wrong mailing list :) > If I understand you correctly, you're saying that while the > MN is at Home, if a new advertisement is received with a new > prefix, how does it know that this is not another foreign subnet. > Well based on my rusty knowledge of ND and stateless address > configuration, it doesnt know. But I don't think that this is > strictly > a MIP issue. While you're at home MIP does not do anything > for you. So that's why I'll cc IPng on this to see if someone can > give you a better answer, or maybe I missed something here. > BTW FA's do not exist in MIPv6. > Reading through section 10.4 of the MIPv6 draft (version 12), I get the impression that: 1. Movement detection is not a simple problem to solve. The draft doesn't really specifiy what method should be used. 2. Seeing an adverisement from a router with a different prefix is not a good way to detect movement. The preferred movement detection method seems to be loss of reachability of the MN's default router, which is noticed through neighbor unreachability detection and/or use of the router advertisement interval option. > > > > > > I also can't find RFC or draft which define exactly address list in a > > MIPv6 MN. A IPv6 node have a address list and every prefix has lifetime. > > Please give me some advice on it. > > > > > > > You may want to take a look at section 5.2 of RFC 2462, which mentions the address list. I hope this is helpful. ------------------------------------------------------------------- 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 Fri Oct 20 01:59: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 BAA00306 for ; Fri, 20 Oct 2000 01:59:48 -0400 (EDT) Received: from standards (47.234.32.16:1326) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7A94@standards.nortelnetworks.com>; Fri, 20 Oct 2000 1:42:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32109 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 01:42:32 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:58564) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7A92@standards.nortelnetworks.com>; Fri, 20 Oct 2000 1:42:31 -0400 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 PAA03536 for ; Fri, 20 Oct 2000 15:54:49 +1000 (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 QAA20863 for ; Fri, 20 Oct 2000 16:57:14 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id <4XFQ44LT>; Fri, 20 Oct 2000 16:57:25 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613CD6@eaubrnt018.epa.ericsson.se> Date: Fri, 20 Oct 2000 16:57:24 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] MIPv6 node location detection To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > I thought that the idea was to have the home agent advertise all > of the "available" prefixes. If the mobile node is on a link that > doesn't have a home agent, then it should still be able to listen > for regular advertisements, but then it doesn't have to worry about > renumbering its home address. Whatever strategy is realistic for > renumbering non-mobile nodes, will also work for mobile nodes > and their care-of addresses. > => My main concern was that we shouldn't have routers advertising with the H bit set and not act as HAs, which is what was suggested for the case when the MN is in a foreign network. I didn't see a reason for that and it is against the current standard. > I don't think there is any problem here. I thought that the only > problem was when the mobile node might have been away from > home for long enough to miss out on some transitional advertisements > from its home agent. Is there something else? > => If you mean "if the MN is turned off for a long time ?" then I agree. Because the MN can still receive the renumbering information from the HA while it's away. Unless I misunderstood the renumbering chapter ? My understanding is that the HA will take important information (like renumbering) out of the advertisements on link and forward them to the MN when it's away. The only problem I see is if the MN is turned off for a very long period of time (does not register with the HA) and does not receive this information. > "Hesham Soliman (EPA)" wrote: > > > > On Wed, 18 Oct 2000, Jarno Rajahalme wrote: > > > > > > > John F. Leser wrote: > > > > > - Then, whenever a MN receives an RA with the H bit set, it will > know > > > > > with certainty whether that RA came from the current home or > foreign > > > > > network, or from some new network, based on whether the prefix of > the > > > > > MN's home or current CO address is advertised in the RA. This way, > > > > > movement onto a new link is detected as soon as any home agent on > that > > > > > link sends an advertisement. > > > > > > > > > > > > > What if the MN never receives a RA with the H bit set? > > > > > > Then the mobile node falls back on some slower mode of movement > > > detection. > > > > > => I'm not sure why you're emphasising the 'H' bit. > > The H bit is only a flag that means "I'm a HA". > > It does NOT mean "I'm YOUR HA". So having said that, > > I would say you don't have to worry about having the HA > > tell if you're at home or not. You know that from the RA, > > whether it comes from your HA or another router. > > > > > > I hope you do not assume all links have home agents. > > > > > > > Routers could be configured to fill this role while not accepting home > > > registrations by setting the H bit and inclunding a home agent > information > > > option with 0 home agent lifetime (This is currently against spec, but > > > could be defined to mean 'I have complete prefix information but will > not > > > serve as a home agent') Or, perhapse it would be better/cleaner to > define > > > another bit the RA to indicate that this router has the complete > prefix > > > list. > > > > > => Why not just advertise the RA ? What is the point > > of the H bit ? > > > > I'd like to repeat a comment that was said before. > > A MN does not have to move when it has a new > > prefix. It has to move when it hears a new prefix > > and the old default router disappears. > > > > If you think that it is too slow to probe the old router > > then you can move as soon as you hear a new prefix. > > This is ok as long as you don't oscillate. > > > > Hesham From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 20 08:07: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 IAA27227 for ; Fri, 20 Oct 2000 08:07:46 -0400 (EDT) Received: from standards (47.234.32.16:1203) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7DDC@standards.nortelnetworks.com>; Fri, 20 Oct 2000 7:50:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33115 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 07:50:16 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7DDA@standards.nortelnetworks.com>; Fri, 20 Oct 2000 7:50:15 -0400 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 e9KC4qs32428; Fri, 20 Oct 2000 14:04:53 +0200 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 OAA16095; Fri, 20 Oct 2000 14:04:51 +0200 (MET DST) 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 OAA89340; Fri, 20 Oct 2000 14:09:29 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200010201209.OAA89340@givry.rennes.enst-bretagne.fr> Date: Fri, 20 Oct 2000 14:09:29 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: "John F. Leser" X-cc: Thomas Eklund , ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Wed, 18 Oct 2000 11:10:50 EDT. In your previous mail you wrote: With this in mind, I'd like to suggest this as an idea for movement detection: - Require that a home agent's router advertisements always contain all of the prefixes on the network that are valid for home or CO addresses. => according to other messages your idea is to overload the meaning of the H flag with "this RA announces all the prefixes"... I don't think it is a good idea but if to know the number of prefixes (there are some optimizations where this info is needed) is very useful then why not a new extension with it in any RA? - Then, whenever a MN receives an RA with the H bit set, it will know with certainty whether that RA came from the current home or foreign network, or from some new network, based on whether the prefix of the MN's home or current CO address is advertised in the RA. This way, movement onto a new link is detected as soon as any home agent on that link sends an advertisement. => this is not protected against a rogue RA and doesn't work with overlapping cells (which seems to need the help of the layer two). - Whenever an RA is received indicating movement onto a new link, the MN transitions neigbor cache entry for the old default router(s) to stale, to accelerate unreachability detection. => move the state to incomplete is more aggressive (faster but more expensive if there is no real movement). I'm curious what people think of this. => I think to rely on RAs for movement detection is not very good because if this should be fast then the frequency of RAs has to be very high (ie. higher than reasonnable). And this is dedicated to a very special scenario (the cellular one) when there are many of them. In this list (mobile IP) many of us did shout that cellular != wireless != mobile, please add me... Regards Francis.Dupont@enst-bretagne.fr PS: the only very clear indication you can get from a RA is to receive an announce for the home prefix(es) where you are in visit. In other cases you can only suspect a movement. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 20 08:15: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 IAA28258 for ; Fri, 20 Oct 2000 08:15:50 -0400 (EDT) Received: from standards (47.234.32.16:1203) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7E20@standards.nortelnetworks.com>; Fri, 20 Oct 2000 7:55:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33201 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 07:55:24 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7E1E@standards.nortelnetworks.com>; Fri, 20 Oct 2000 7:55:23 -0400 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 e9KCANs29026; Fri, 20 Oct 2000 14:10:23 +0200 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 OAA16929; Fri, 20 Oct 2000 14:10:21 +0200 (MET DST) 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 OAA89401; Fri, 20 Oct 2000 14:15:00 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200010201215.OAA89401@givry.rennes.enst-bretagne.fr> Date: Fri, 20 Oct 2000 14:14:59 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: "Hesham Soliman (EPA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Thu, 19 Oct 2000 09:51:05 +1100. <4B6BC00CD15FD2119E5F0008C7A419A50C613CBB@eaubrnt018.epa.ericsson.se> In your previous mail you wrote: I'd like to repeat a comment that was said before. A MN does not have to move when it has a new prefix. It has to move when it hears a new prefix and the old default router disappears. => I'll agree if you change "the old default router" by "old default routers". If you think that it is too slow to probe the old router then you can move as soon as you hear a new prefix. This is ok as long as you don't oscillate. => I think it is important to be protected against rogue router advertisements... The only scenario discussed here is the cellular one and usually it is not the kind of media with the lowest error rate. And of course there is the case of overlapping cells. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 20 08:33: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 IAA00586 for ; Fri, 20 Oct 2000 08:33:19 -0400 (EDT) Received: from standards (47.234.32.16:1203) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7EEE@standards.nortelnetworks.com>; Fri, 20 Oct 2000 8:16:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33423 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 08:16:05 -0400 Received: from porter.avnet.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7EC8@standards.nortelnetworks.com>; Fri, 20 Oct 2000 8:06:04 -0400 Received: from smtp1.avnet.com (root@smtp1 [172.16.26.246]) by porter.avnet.com (8.9.3/8.9.3) with ESMTP id FAA14178 for ; Fri, 20 Oct 2000 05:21:19 -0700 (MST) Received: from amer11.avnet.com (amer11.avnet.com [172.16.125.232]) by smtp1.avnet.com (8.9.3 (PHNE_18546)/8.9.3) with ESMTP id FAA04847 for ; Fri, 20 Oct 2000 05:21:18 -0700 (MST) Received: by amer11.avnet.com with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Oct 2000 05:21:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 20 Oct 2000 05:21:16 -0700 Reply-To: "Karan, Karuna" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Karan, Karuna" Subject: [MOBILE-IP] Pls change my email id To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Pls change my email id to karunamenon@aol.com and delete my email id karuna.karan@avnet.com fm your address. thanks..karuna From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 20 08:41: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 IAA01572 for ; Fri, 20 Oct 2000 08:41:05 -0400 (EDT) Received: from standards (47.234.32.16:1203) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7F14@standards.nortelnetworks.com>; Fri, 20 Oct 2000 8:19:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33518 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 08:19:16 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7F12@standards.nortelnetworks.com>; Fri, 20 Oct 2000 8:19:15 -0400 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 e9KCY3s35093; Fri, 20 Oct 2000 14:34:03 +0200 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 OAA17622; Fri, 20 Oct 2000 14:34:02 +0200 (MET DST) 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 OAA89575; Fri, 20 Oct 2000 14:38:40 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200010201238.OAA89575@givry.rennes.enst-bretagne.fr> Date: Fri, 20 Oct 2000 14:38:39 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: Nakhjiri Madjid-MNAKHJI1 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Thu, 19 Oct 2000 16:33:05 CDT. <0DF9920C9AD8D211AB0C0008C7CF1C9A0498FB95@il27exm02.cig.mot.com> Please look at Link-shared secrets for ND presented by D. McDonald in March at the IETF meeting in Adelaide (to protect ND with IPsec will improve many things but a good way to spread secrets is needed). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 20 11:28: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 LAA02252 for ; Fri, 20 Oct 2000 11:28:34 -0400 (EDT) Received: from standards (47.234.32.16:3281) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8099@standards.nortelnetworks.com>; Fri, 20 Oct 2000 11:11:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33996 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 11:11:17 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8097@standards.nortelnetworks.com>; Fri, 20 Oct 2000 11:11:16 -0400 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 IAA25702; Fri, 20 Oct 2000 08:26:32 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9KFQTW30220; Fri, 20 Oct 2000 08:26:29 -0700 X-Virus-Scanned: Fri, 20 Oct 2000 08:26:29 -0700 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) smtpdrFlYxk; Fri, 20 Oct 2000 08:26:26 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <200010201215.OAA89401@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39F06424.F9788829@iprg.nokia.com> Date: Fri, 20 Oct 2000 08:26:28 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: Francis.Dupont@ENST-BRETAGNE.FR To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Francis, > If you think that it is too slow to probe the old router > then you can move as soon as you hear a new prefix. > This is ok as long as you don't oscillate. > > => I think it is important to be protected against rogue router > advertisements... The only scenario discussed here is the cellular one > and usually it is not the kind of media with the lowest error rate. > And of course there is the case of overlapping cells. My radar is tuned to finding things that need to be changed in the specification for the next revision. I don't think this represents a "Mobile IPv6" problem. I think it is a more basic problem with Neighbor Advertisements, and as such we should not try to fix it in the Mobile IPv6 specification. Does this sound reasonable? I hope so, because I am very much hoping to avoid the big delay that fixing this problem would represent. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 20 12:08: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 MAA07455 for ; Fri, 20 Oct 2000 12:08:11 -0400 (EDT) Received: from standards (47.234.32.16:3281) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8123@standards.nortelnetworks.com>; Fri, 20 Oct 2000 11:50:57 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34133 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 11:50:56 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8101@standards.nortelnetworks.com>; Fri, 20 Oct 2000 11:40:55 -0400 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 e9KFuBt14912; Fri, 20 Oct 2000 17:56:11 +0200 (MEST) Received: from e00105a2d1ed7 by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id RAA09528; Fri, 20 Oct 2000 17:56:10 +0200 X-Sender: erajoaa@era-t.ericsson.se X-Mailer: Windows Eudora Pro Version 3.0 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.32.20001020175404.00e8470c@era-t.ericsson.se> Date: Fri, 20 Oct 2000 17:54:04 +0200 Reply-To: Annika Jonsson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Annika Jonsson Subject: Re: [MOBILE-IP] WG Last Call -(draft-ietf-mobileip-reg-tunnel-03.txt) X-To: Gopal Dommety To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM 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 Oct 20 12:25: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 MAA09601 for ; Fri, 20 Oct 2000 12:25:17 -0400 (EDT) Received: from standards (47.234.32.16:3281) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8186@standards.nortelnetworks.com>; Fri, 20 Oct 2000 12:08:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34307 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 12:08:08 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8184@standards.nortelnetworks.com>; Fri, 20 Oct 2000 12:08:07 -0400 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 e9KGNIs43434; Fri, 20 Oct 2000 18:23:19 +0200 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 SAA26019; Fri, 20 Oct 2000 18:23:18 +0200 (MET DST) 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 SAA90984; Fri, 20 Oct 2000 18:27:57 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200010201627.SAA90984@givry.rennes.enst-bretagne.fr> Date: Fri, 20 Oct 2000 18:27:57 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Fri, 20 Oct 2000 08:26:28 PDT. <39F06424.F9788829@iprg.nokia.com> In your previous mail you wrote: > If you think that it is too slow to probe the old router > then you can move as soon as you hear a new prefix. > This is ok as long as you don't oscillate. > > => I think it is important to be protected against rogue router > advertisements... The only scenario discussed here is the cellular one > and usually it is not the kind of media with the lowest error rate. > And of course there is the case of overlapping cells. My radar is tuned to finding things that need to be changed in the specification for the next revision. I don't think this represents a "Mobile IPv6" problem. => I agree. In fact I think all the movement detection stuff should not slow down the Mobile IPv6 draft because they are out of the scope (ie. if there are too many things to say about this, another document should be produced). As soon as neighbor discovery is correctly used in the mobility draft no change are needed (then only MUST in 10.19 should be changed, to do a DAD for the home agent address is an extreme solution then should be used only when nothing else can work: IMHO the MUST is too strong). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Oct 21 00:10: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 AAA23569 for ; Sat, 21 Oct 2000 00:10:05 -0400 (EDT) Received: from standards (47.234.32.16:4645) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA83B9@standards.nortelnetworks.com>; Fri, 20 Oct 2000 23:52:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35009 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 23:52:42 -0400 Received: from mail.xnet.com (quake.xnet.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA83AC@standards.nortelnetworks.com>; Fri, 20 Oct 2000 23:42:41 -0400 Received: from piii (wizkid11.xnet.com [205.243.139.135]) by mail.xnet.com (8.9.3+Sun/XNet-3.0R) with SMTP id WAA28265 for ; Fri, 20 Oct 2000 22:57:56 -0500 (CDT) References: <3.0.32.20001020175404.00e8470c@era-t.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <004d01c03b11$82ec9740$878bf3cd@piii> Date: Fri, 20 Oct 2000 22:46:34 -0500 Reply-To: Satwant Kaur Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Satwant Kaur Subject: Re: [MOBILE-IP] WG Last Call -(draft-ietf-mobileip-reg-tunnel-03.txt) To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit 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). 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" To: 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 Sat Oct 21 00:48: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 AAA01635 for ; Sat, 21 Oct 2000 00:48:35 -0400 (EDT) Received: from standards (47.234.32.16:4645) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8470@standards.nortelnetworks.com>; Sat, 21 Oct 2000 0:31:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35272 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 21 Oct 2000 00:31:29 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:38198) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA846E@standards.nortelnetworks.com>; Sat, 21 Oct 2000 0:31:28 -0400 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 OAA29468 for ; Sat, 21 Oct 2000 14:43:45 +1000 (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 PAA00387 for ; Sat, 21 Oct 2000 15:46:11 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id <4XFQ490B>; Sat, 21 Oct 2000 15:46:22 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613CDB@eaubrnt018.epa.ericsson.se> Date: Sat, 21 Oct 2000 15:46:21 +1100 Reply-To: "Hesham Soliman (EPA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Hesham Soliman (EPA)" Subject: Re: [MOBILE-IP] MIPv6 node location detection To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > I'm curious what people think of this. > > => I think to rely on RAs for movement detection is not very good because > if this should be fast then the frequency of RAs has to be very high > (ie. higher than reasonnable). And this is dedicated to a very special > scenario (the cellular one) when there are many of them. In this list > (mobile IP) many of us did shout that cellular != wireless != mobile, > please add me... > => I agree that we don't need very frequent RA's, and that other optimisations are required for faster handoffs. If I understood your statement correctly, you seem to suggest that cellular systems don't mind this frequent RAs idea. As far as I know sending very frequent RAs is NOT a good idea for cellular systems as radio resources are more scarce and expensive in these types of lnks than in other wireless environment. So the less RAs sent, the more efficient systems are in terms of radio use. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Oct 21 01:52: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 BAA28776 for ; Sat, 21 Oct 2000 01:52:09 -0400 (EDT) Received: from standards (47.234.32.16:4885) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA84D8@standards.nortelnetworks.com>; Sat, 21 Oct 2000 1:34:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35402 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 21 Oct 2000 01:34:53 -0400 Received: from snipe.prod.itd.earthlink.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA84D2@standards.nortelnetworks.com>; Sat, 21 Oct 2000 1:24:52 -0400 Received: from mail.earthlink.net (sdn-ar-001flpcitP309.dialsprint.net [158.252.74.47]) by snipe.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id WAA22198; Fri, 20 Oct 2000 22:38:58 -0700 (PDT) Received: from pianoinfode@yahoo.com by pianoinfodev@yahoo.com (8.8.5/8.6.5) with SMTP id GAA05423 for ; Fri, 20 Oct 2000 23:44:38 -0600 (EST) Message-ID: <> Date: Fri, 20 Oct 2000 23:44:38 EST Reply-To: pianoinfode@YAHOO.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: pianoinfode@YAHOO.COM Subject: [MOBILE-IP] INFO ON PIANO PLAYING X-To: pianoinfodev@yahoo.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM THIS IS ABSOLUTELY INCREDIBLE!!! PIANO OWNERS- we offer a patented device that sits on your piano keyboard and allows you to play the piano immediately!! For more detailed information click Pianotech@iar.net type more info in the subject line! You may also reach us at 1-888-279-4455 for more info on this exciting product. If we have reached you in error and you would like to be removed from our mailing list starlete@china.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Oct 21 01:52: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 BAA28782 for ; Sat, 21 Oct 2000 01:52:10 -0400 (EDT) Received: from standards (47.234.32.16:4885) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA84E1@standards.nortelnetworks.com>; Sat, 21 Oct 2000 1:34:57 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35403 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 21 Oct 2000 01:34:57 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA84D3@standards.nortelnetworks.com>; Sat, 21 Oct 2000 1:24:56 -0400 Received: from snipe.prod.itd.earthlink.net (snipe.prod.itd.earthlink.net [207.217.120.62]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id AAA08663 for ; Sat, 21 Oct 2000 00:40:09 -0500 (CDT) Received: from mail.earthlink.net (sdn-ar-001flpcitP309.dialsprint.net [158.252.74.47]) by snipe.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id WAA22198; Fri, 20 Oct 2000 22:38:58 -0700 (PDT) Received: from pianoinfode@yahoo.com by pianoinfodev@yahoo.com (8.8.5/8.6.5) with SMTP id GAA05423 for ; Fri, 20 Oct 2000 23:44:38 -0600 (EST) Message-ID: <> Date: Fri, 20 Oct 2000 23:44:38 EST Reply-To: pianoinfode@YAHOO.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: pianoinfode@YAHOO.COM Subject: [MOBILE-IP] INFO ON PIANO PLAYING X-To: pianoinfodev@yahoo.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM THIS IS ABSOLUTELY INCREDIBLE!!! PIANO OWNERS- we offer a patented device that sits on your piano keyboard and allows you to play the piano immediately!! For more detailed information click Pianotech@iar.net type more info in the subject line! You may also reach us at 1-888-279-4455 for more info on this exciting product. If we have reached you in error and you would like to be removed from our mailing list starlete@china.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Oct 21 10:13: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 KAA07185 for ; Sat, 21 Oct 2000 10:13:52 -0400 (EDT) Received: from standards (47.234.32.16:2050) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA879C@standards.nortelnetworks.com>; Sat, 21 Oct 2000 9:56:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36387 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 21 Oct 2000 09:56:35 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA879A@standards.nortelnetworks.com>; Sat, 21 Oct 2000 9:56:35 -0400 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 e9LEBfs29491; Sat, 21 Oct 2000 16:11:41 +0200 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 QAA22991; Sat, 21 Oct 2000 16:11:40 +0200 (MET DST) 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 QAA96792; Sat, 21 Oct 2000 16:16:24 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200010211416.QAA96792@givry.rennes.enst-bretagne.fr> Date: Sat, 21 Oct 2000 16:16:24 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: "Hesham Soliman (EPA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Sat, 21 Oct 2000 15:46:21 +1100. <4B6BC00CD15FD2119E5F0008C7A419A50C613CDB@eaubrnt018.epa.ericsson.se> In your previous mail you wrote: => I agree that we don't need very frequent RA's, and that other optimisations are required for faster handoffs. If I understood your statement correctly, you seem to suggest that cellular systems don't mind this frequent RAs idea. => it is not exactly my point: - frequent RAs is not a good idea - this idea applies only to cellular systems which are only a part of all situations where mobile IP is useful. Then my concern is we can put too much energy to improve a shaky solution for a special case... As far as I know sending very frequent RAs is NOT a good idea for cellular systems as radio resources are more scarce and expensive in these types of lnks than in other wireless environment. So the less RAs sent, the more efficient systems are in terms of radio use. => then you agree at least on the first part. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Oct 21 17:07: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 RAA25169 for ; Sat, 21 Oct 2000 17:06:59 -0400 (EDT) Received: from standards (47.234.32.16:4496) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8A5E@standards.nortelnetworks.com>; Sat, 21 Oct 2000 16:49:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37289 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 21 Oct 2000 16:49:50 -0400 Received: from smtp-2.hut.fi by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8A5A@standards.nortelnetworks.com>; Sat, 21 Oct 2000 16:39:49 -0400 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 XAA07853; Sat, 21 Oct 2000 23:55:04 +0300 (EEST) 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.20001020175404.00e8470c@era-t.ericsson.se> <004d01c03b11$82ec9740$878bf3cd@piii> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <39F202AC.AC847877@cc.hut.fi> Date: Sat, 21 Oct 2000 23:55:08 +0300 Reply-To: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" Organization: HUT Subject: Re: [MOBILE-IP] WG Last Call-(draft-ietf-mobileip-reg-tunnel-03.txt) X-To: Satwant Kaur To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hi, In my opinion, additional messages makes the protocol partly clearer, but partly more complex. Here are my questions (please point me to the appropriate messages, if these questions have already been discussed :) - Is it possible/needed that a FA does not know the GFA or GFAs above it? I think FAs and GFAs should have trust relationships = knowledge of each other. - Why do we need to add intelligence to the mobile node? Having a totally transparent hierarchy is possible. The MN would speak standard RFC2002 MIP and would still get the best efficiency in registrations through the regionalized handoffs. By defining new messages we do add intelligence to MN. It must know what kind of registrations to send. And my totally subjective opinion: ;-) Despite the lively discussion about regionalized handoffs etc., I still have not seen many transparent, fast and *implemented* approaches. If the ideas in the drafts have been implemented, please provide the community some links to the material. Dynamics - HUT Mobile IP has been rocking for 1.5 years now. Dynamics is transparent to the Mobile Node and still provides fast handoffs. Should we write a competing draft? ;-) We didn't do it in the first place because we felt it would just slow down the fast handoff design process. Unfortunately the process has been unbelievably slow. I am really looking forward to a solution in this issue. Regards, Tom -- Tom Weckström Dynamics group Helsinki University of Technology dynamics@cs.hut.fi http://www.cs.hut.fi/Research/Dynamics/ 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). > > 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" > To: > 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 Sat Oct 21 18:20: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 SAA03151 for ; Sat, 21 Oct 2000 18:20:21 -0400 (EDT) Received: from standards (47.234.32.16:2936) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8AC2@standards.nortelnetworks.com>; Sat, 21 Oct 2000 18:03:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37418 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 21 Oct 2000 18:03:17 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8ABA@standards.nortelnetworks.com>; Sat, 21 Oct 2000 17:53:17 -0400 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 PAA01107; Sat, 21 Oct 2000 15:08:36 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9LM8XC25793; Sat, 21 Oct 2000 15:08:33 -0700 X-Virus-Scanned: Sat, 21 Oct 2000 15:08:33 -0700 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) smtpd4Oeqx2; Sat, 21 Oct 2000 15:08:29 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <39DB6C48.8D2BE6E2@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39F213DF.B2223DF7@iprg.nokia.com> Date: Sat, 21 Oct 2000 15:08:31 -0700 Reply-To: vijayd@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Vijay Devarapalli Subject: Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySupport in IPv6"draft] X-To: charliep@iprg.nokia.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Charlie. see my comments below "Charles E. Perkins" wrote: > Hello folks, > > I would like to mandate (i.e., MUST) the simplest possible > strategy, to wit: > > 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. > > Of course, this also means that the node receiving a packet > with AH will have to follow the same algorithm, which > basically just means not moving data fields at all. > The only complication comes when it is necessary to look up > the appropriate security association for processing either > AH or ESP. That lookup, typically indexed by the > Source IP address of the IPv6 header, would instead have > to be indexed by the home address in the Home Address > destination option. Since that destination option would > occur in the packet _before_ the security header, > processing is still very simple. > This makes the implementation of the ip_input function difficult for those packets which carry the Home Address option before the AH. In particular, I wouldnt know when to exactly replace the CoA with the Home address in the source of the packet. Consider the case where a CN/Home Agent receives a BU. The packet could be like this IPv6 header, HA dest hdr, AH, BU dest hdr, TCP hdr. The ip_input() function most often is a protocol switch which just calls the corresponding protocol handler for each protocol header that it encounters. I need to replace the CoA with home address before I give it to the module which handles TCP. I have three options 1. do the switch in the BU handling function 2. do the switch in ip_input function before calling the upper layer functions 3. do the switch in the tcp module. Consider another case where the packet is IPv6 header, HA dest hdr, ICMP Now I have two options 1. do the switch in ip_input function before calling the upper layer functions 2. do the switch in the ICMP module Yet another case could be IPv6 hdr, HA dest hdr, Frag hdr, AH, BU, ICMP In this case I would have to do the switch before the frag header is processed. Now both the AH module and the BU handler need to be aware for this. Therefore the best and the easiest thing to do would be do the switch when the HA dest hdr is processed. Then AH proceeds normally. The BU handler alone needs to know where the CoA is stored (could be a pointer / in the HA dest hdr after the switch) I would like to propose the following. On the Mobile Node side Before AH checksum calculation switch the contents of the source address of the packet and the Home Address dest option (the source address would be CoA already). This way the CoA is also protected. This switch is not a big deal because, most oftenAH implementation would require creating another text string or mbuf(with mutable fields zeroed out). The checksum is calculated on this text string. The original mbuf is left intact. On the CN / Home Agent side 1. Process IPv6 header. 2. Process Home Address option. Do the switch. Store the CoA in the Home Address option. Maybe use a bit to indicate this. 3. Process AH naturally. Security Association is chosen based on the source address of the packet. 4. Process BU. Only this module needs to know that the CoA is store in the Home Address option. 5. Call each protocol handler. In my opinion, the above makes things easy to implement. Comments are welcome. Regards Vijay From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Oct 22 11:34: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 LAA05642 for ; Sun, 22 Oct 2000 11:34:57 -0400 (EDT) Received: from standards (47.234.32.16:1997) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8D54@standards.nortelnetworks.com>; 22 Oct 2000 11:17:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 38365 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 22 Oct 2000 11:17:11 -0400 Received: from qhars002.nortel.com (47.101.112.102:63837) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8D52@standards.nortelnetworks.com>; 22 Oct 2000 11:17:11 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Sun, 22 Oct 2000 16:32:29 +0100 Received: from zrchs148 by smtprch1.nortel.com; Sun, 22 Oct 2000 10:32:26 -0500 Received: from zrchb200.us.nortel.com (actually zrchb200) by zrchs148; Sun, 22 Oct 2000 10:24:43 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id <4VMD12DA>; Sun, 22 Oct 2000 10:32:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03C3D.457067C0" Message-ID: <36FA02BD7083D411BC9E0000F8073E438CEF17@crchy271.us.nortel.com> Date: Sun, 22 Oct 2000 10:32:22 -0500 Reply-To: Glenn Morrow Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Glenn Morrow Subject: Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup port in IPv6"draft] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM ------_=_NextPart_001_01C03C3D.457067C0 Content-type: text/plain; charset="us-ascii" > Consider the case where a CN/Home Agent receives a BU. The packet could be > like this > > IPv6 header, HA dest hdr, AH, BU dest hdr, TCP hdr. [[gm]] consider this: IPv6 header, HA dest hder, AH, BU dest hdr, SIP Invite How does one know whether the authenitication parameters related to the binding update are the same as the parameters related to the SIP Invite or for that matter - any application? Are we making some assumptions here about business models that perhaps we shouldn't? Is it possible to have more than one AH header with different checksum boundaries? ------_=_NextPart_001_01C03C3D.457067C0 Content-type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of = "MobilitySupport in IPv6"draft]

Consider the case where a CN/Home = Agent receives a BU. The packet could be
like this

        IPv6 header, = HA dest hdr, AH, BU dest hdr, TCP hdr.
[[gm]]  consider this:

        IPv6 header, HA dest hder, AH, BU dest hdr, SIP = Invite

How does one know = whether the authenitication parameters related to the binding update = are the same as the parameters related to the SIP Invite or for that = matter - any application?

Are we making some = assumptions here about business models that perhaps we shouldn't? =

Is it possible to = have more than one AH header with different checksum boundaries?


------_=_NextPart_001_01C03C3D.457067C0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 03:38: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 DAA01755 for ; Mon, 23 Oct 2000 03:38:36 -0400 (EDT) Received: from standards (47.234.32.16:4975) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8FBE@standards.nortelnetworks.com>; Mon, 23 Oct 2000 3:21:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39211 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 03:21:11 -0400 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8FBC@standards.nortelnetworks.com>; Mon, 23 Oct 2000 3:21:10 -0400 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 e9N7aMs41583; Mon, 23 Oct 2000 09:36:23 +0200 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 JAA10946; Mon, 23 Oct 2000 09:36:22 +0200 (MET DST) 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 JAA03346; Mon, 23 Oct 2000 09:36:21 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-ID: <200010230736.JAA03346@givry.rennes.enst-bretagne.fr> Date: Mon, 23 Oct 2000 09:36:21 +0200 Reply-To: Francis.Dupont@ENST-BRETAGNE.FR Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup port in IPv6"draft] X-To: Glenn Morrow To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Sun, 22 Oct 2000 10:32:22 CDT. <36FA02BD7083D411BC9E0000F8073E438CEF17@crchy271.us.nortel.com> In your previous mail you wrote: IPv6 header, HA dest hder, AH, BU dest hdr, SIP Invite How does one know whether the authenitication parameters related to the binding update are the same as the parameters related to the SIP Invite or for that matter - any application? Are we making some assumptions here about business models that perhaps we shouldn't? Is it possible to have more than one AH header with different checksum boundaries? => I don't understand the last statement (AH covers the whole packet) then I don't understand the issue here... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 04:56: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 EAA25288 for ; Mon, 23 Oct 2000 04:56:37 -0400 (EDT) Received: from standards (47.234.32.16:2947) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9066@standards.nortelnetworks.com>; Mon, 23 Oct 2000 4:39:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39416 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 04:39:12 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9062@standards.nortelnetworks.com>; Mon, 23 Oct 2000 4:29:10 -0400 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 e9N8iYt04986; Mon, 23 Oct 2000 10:44:34 +0200 (MEST) Received: from e00105a2d1ed7 by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id KAA08438; Mon, 23 Oct 2000 10:44:34 +0200 X-Sender: erajoaa@era-t.ericsson.se X-Mailer: Windows Eudora Pro Version 3.0 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <3.0.32.20001023104432.0068c9bc@era-t.ericsson.se> Date: Mon, 23 Oct 2000 10:44:33 +0200 Reply-To: Annika Jonsson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Annika Jonsson Subject: Re: [MOBILE-IP] WG Last Call-(draft-ietf-mobileip-reg-tunnel-03.txt) X-To: "=?iso-8859-1?Q?=22Tom_K._Weckstr=F6m=22?=" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA25288 Hi Tom, see comments below. At 23:55 2000-10-21 +0300, Tom K. Weckström wrote: >Hi, > >In my opinion, additional messages makes the protocol partly clearer, >but partly more complex. > >Here are my questions (please point me to the appropriate messages, if >these questions have already been discussed :) > >- Is it possible/needed that a FA does not know the GFA or GFAs above >it? >I think FAs and GFAs should have trust relationships = knowledge of >each other. Yes, FA:s and GFA:s need to know about each other. That is also stated in the draft (well, indirectly, since it says that they need to have established security associations between them). > >- Why do we need to add intelligence to the mobile node? >Having a totally transparent hierarchy is possible. The MN would speak >standard RFC2002 MIP and would still get the best efficiency in >registrations through the regionalized handoffs. By defining new >messages we do add intelligence to MN. It must know what kind of >registrations to send. > Because, as I said in my last mail, the MN needs to know if the registration request will be processed in the home or in the visited domain to know which security association and replay protection to use. We didn't find any way to get around this. But another goal is to support RFC2002 MN:s also. In this draft, they don't get the benefits of the regional registrations, but they will work. /Annika >And my totally subjective opinion: > ;-) >Despite the lively discussion about regionalized handoffs etc., I >still have not seen many transparent, fast and *implemented* >approaches. If the ideas in the drafts have been implemented, please >provide the community some links to the material. Dynamics - HUT >Mobile IP has been rocking for 1.5 years now. Dynamics is transparent >to the Mobile Node and still provides fast handoffs. > >Should we write a competing draft? ;-) We didn't do it in the first >place because we felt it would just slow down the fast handoff design >process. Unfortunately the process has been unbelievably slow. I am >really looking forward to a solution in this issue. > >Regards, > Tom > >-- > Tom Weckström Dynamics group > Helsinki University of Technology > dynamics@cs.hut.fi > >http://www.cs.hut.fi/Research/Dynamics/ > > >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). >> >> 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" >> To: >> 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 Mon Oct 23 11: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 LAA24012 for ; Mon, 23 Oct 2000 11:08:05 -0400 (EDT) Received: from standards (47.234.32.16:4677) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA922F@standards.nortelnetworks.com>; Mon, 23 Oct 2000 10:50:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 40025 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 10:50:33 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA922D@standards.nortelnetworks.com>; Mon, 23 Oct 2000 10:50:32 -0400 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 IAA26383; Mon, 23 Oct 2000 08:05:57 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9NF5tv09801; Mon, 23 Oct 2000 08:05:55 -0700 X-Virus-Scanned: Mon, 23 Oct 2000 08:05:55 -0700 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) smtpdn8lay6; Mon, 23 Oct 2000 08:05:51 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <36FA02BD7083D411BC9E0000F8073E438CEF17@crchy271.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39F453D1.6070B8BE@iprg.nokia.com> Date: Mon, 23 Oct 2000 08:05:53 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySupport inIPv6"draft] X-To: Glenn Morrow To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Glenn, You asked: > [[gm]] consider this: > > IPv6 header, HA dest hder, AH, BU dest hdr, SIP Invite > > How does one know whether the authenitication parameters related to the > binding update are the same as the parameters related to the SIP Invite or for > that matter - any application? AH is for _network layer_ binding. It does not give any assurance that application is authorized to offer the services or interactions peculiar to that application. If there is a way for an application to get installed on a host that it should not be running on, then that application _can_ "subvert" the network-layer security infrastructure. Does this answer your question? > Are we making some assumptions here about business models that perhaps we > shouldn't? The distance between business models and network-layer security is farther than I can usefully comprehend. > Is it possible to have more than one AH header with different checksum > boundaries? Not as far as I know. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 12:17:57 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06533 for ; Mon, 23 Oct 2000 12:17:56 -0400 (EDT) Received: from standards (47.234.32.16:4677) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA931C@standards.nortelnetworks.com>; Mon, 23 Oct 2000 12:00:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 40325 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 12:00:08 -0400 Received: from qhars002.nortel.com (47.101.112.102:54256) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA931A@standards.nortelnetworks.com>; Mon, 23 Oct 2000 12:00:08 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Mon, 23 Oct 2000 17:15:20 +0100 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Mon, 23 Oct 2000 10:47:01 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id <4VMD1VA9>; Mon, 23 Oct 2000 10:46:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03D08.7389D760" Message-ID: <36FA02BD7083D411BC9E0000F8073E438CEF19@crchy271.us.nortel.com> Date: Mon, 23 Oct 2000 10:46:47 -0500 Reply-To: Glenn Morrow Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Glenn Morrow Subject: Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup port inIPv6"draft] X-To: "charliep@IPRG.NOKIA.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_001_01C03D08.7389D760 Content-Type: text/plain Hi Charlie, See below: > > [[gm]] consider this: > > > > IPv6 header, HA dest hder, AH, BU dest hdr, SIP Invite > > > > How does one know whether the authenitication parameters related to the > > binding update are the same as the parameters related to the SIP Invite > or for > > that matter - any application? > > AH is for _network layer_ binding. > > It does not give any assurance that application is authorized > to offer the services or interactions peculiar to that application. > If there is a way for an application to get installed on a host > that it should not be running on, then that application _can_ > "subvert" the network-layer security infrastructure. > > Does this answer your question? [[gm]] What I thinking was that users may have more than one identity and therefore credentials for authorization. One set of credentials may relate to service for an application and the other relate to credentials for network layer access which I believe node mobility should be an integral part of. > > Are we making some assumptions here about business models that perhaps > we > > shouldn't? > > The distance between business models and network-layer security > is farther than I can usefully comprehend. [[gm]] The point is simple. I don't think we want to couple ownership and control of applications to the network access ownership in the IETF. > > Is it possible to have more than one AH header with different checksum > > boundaries? > > Not as far as I know. [[gm]] I think we might need something like this if we plan on sending application packets that need to be authorized using the credentials from one identity in the same packet as a binding update that might need authorization using the credentials from another identity. A simple IF statement might work. i.e. if the application part needs authorization using a separate identity then we have to send separate packets? > Regards, > Charlie P. ------_=_NextPart_001_01C03D08.7389D760 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of = "MobilitySupport inIPv6"draft]

Hi Charlie,

See below:

> [[gm]]  consider = this:
>
>         = IPv6 header, HA dest hder, AH, BU dest hdr, SIP Invite
>
> How does one know whether the = authenitication parameters related to the
> binding update are the same as = the parameters related to the SIP Invite or for
> that matter - any = application?

AH is for _network layer_ = binding.

It does not give any assurance that = application is authorized
to offer the services or interactions = peculiar to that application.
If there is a way for an application = to get installed on a host
that it should not be running on, = then that application _can_
"subvert" the network-layer = security infrastructure.

Does this answer your question?
[[gm]] 
What I thinking was = that users may have more than one identity and therefore credentials = for authorization. One set of credentials may relate to service for an = application and the other relate to credentials for network layer = access which I believe node mobility should be an integral part = of.

> Are we making some assumptions = here about business models that perhaps we
> shouldn't?

The distance between business models = and network-layer security
is farther than I can usefully = comprehend.
[[gm]] 
The point is = simple. I don't think we want to couple ownership and control of = applications to the network access ownership in the IETF.

> Is it possible to have more than = one AH header with different checksum
> boundaries?

Not as far as I know.
[[gm]] 
I think we might = need something like this if we plan on sending application packets that = need to be authorized using the credentials from one identity in the = same packet as a binding update that might need authorization using the = credentials from another identity.

A simple IF = statement might work. i.e. if the application part needs authorization = using a separate identity then we have to send separate = packets?


Regards,
Charlie P.

------_=_NextPart_001_01C03D08.7389D760-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 12:26:40 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08467 for ; Mon, 23 Oct 2000 12:26:39 -0400 (EDT) Received: from standards (47.234.32.16:4677) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9372@standards.nortelnetworks.com>; Mon, 23 Oct 2000 12:08:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 40438 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 12:08:53 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9370@standards.nortelnetworks.com>; Mon, 23 Oct 2000 12:08:53 -0400 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 JAA03404; Mon, 23 Oct 2000 09:24:18 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9NGOFg15883; Mon, 23 Oct 2000 09:24:15 -0700 X-Virus-Scanned: Mon, 23 Oct 2000 09:24:15 -0700 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) smtpdvLxEHs; Mon, 23 Oct 2000 09:24:11 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <36FA02BD7083D411BC9E0000F8073E438CEF19@crchy271.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39F4662D.EA8DD1E4@iprg.nokia.com> Date: Mon, 23 Oct 2000 09:24:13 -0700 Reply-To: charliep@IPRG.NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySupportinIPv6"draft] X-To: Glenn Morrow To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Glenn, What I think you want can _possibly_ be done using AH, if the operating system is sufficiently secure, and the other communication endpoint sufficiently restriced in the services it is configured to offer. But it's definitely NOT an issue for Mobile IP, so I reckon we ought to take it offline. I am pretty sure that you can find megabytes of good technical discussion on this issue if you look at the IPsec mailing list archives. Regards, Charlie P. > Glenn Morrow wrote: > > Hi Charlie, > > See below: > > > [[gm]] consider this: > > > > IPv6 header, HA dest hder, AH, BU dest hdr, SIP Invite > > > > How does one know whether the authenitication parameters related to the > > binding update are the same as the parameters related to the SIP Invite or > for > > that matter - any application? > > AH is for _network layer_ binding. > > It does not give any assurance that application is authorized > to offer the services or interactions peculiar to that application. > If there is a way for an application to get installed on a host > that it should not be running on, then that application _can_ > "subvert" the network-layer security infrastructure. > > Does this answer your question? > [[gm]] > What I thinking was that users may have more than one identity and therefore > credentials for authorization. One set of credentials may relate to service > for an application and the other relate to credentials for network layer > access which I believe node mobility should be an integral part of. > > > Are we making some assumptions here about business models that perhaps we > > shouldn't? > > The distance between business models and network-layer security > is farther than I can usefully comprehend. > [[gm]] > The point is simple. I don't think we want to couple ownership and control of > applications to the network access ownership in the IETF. > > > Is it possible to have more than one AH header with different checksum > > boundaries? > > Not as far as I know. > [[gm]] > I think we might need something like this if we plan on sending application > packets that need to be authorized using the credentials from one identity in > the same packet as a binding update that might need authorization using the > credentials from another identity. > > A simple IF statement might work. i.e. if the application part needs > authorization using a separate identity then we have to send separate packets? > > Regards, > Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 12:33:54 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09992 for ; Mon, 23 Oct 2000 12:33:53 -0400 (EDT) Received: from standards (47.234.32.16:4677) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA93C4@standards.nortelnetworks.com>; Mon, 23 Oct 2000 12:16:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 40414 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 12:16:20 -0400 Received: from hermes.cti.gr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA935F@standards.nortelnetworks.com>; Mon, 23 Oct 2000 12:06:19 -0400 Received: (qmail 22298 invoked by uid 60015); 23 Oct 2000 16:19:51 -0000 Received: from nikole@cti.gr by hermes with scan4virus-0.50 (. Clean. Processed in 0.049099 secs); 23/10/2000 19:19:51 Received: from pc4822.cti.gr (HELO pc4822) (150.140.5.22) by hermes.cti.gr with SMTP; 23 Oct 2000 16:19:51 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Message-ID: <001d01c03d0d$977e9b60$16058c96@cti.gr> Date: Mon, 23 Oct 2000 19:23:34 +0300 Reply-To: nikole@cti.gr Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Sotiris Nikoletseas Subject: [MOBILE-IP] Deadline approaching -- IPDPS Workshop on Mobile Computing To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Please accept my apologies if you receive multiple copies of this message. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ PRELIMINARY CALL FOR PAPERS 1st International Workshop on Parallel and Distributed Computing Issues in Wireless Networks and Mobile Computing IPDPS 2001 WORKSHOPS Hyatt Regency San Francisco April 23-27, 2001 URLs: http://www.ipdps.org http://www.computing.edu.au/~kumar/ipdpswpim.html ++++++++++++++++++++++++++++++++++++++++++++++++ General Chair Sajal K. Das, The University of Texas at Arlington, USA Program Co-Chairs Mohan Kumar, Curtin University of Technology, Perth, Australia and The University of Texas at Arlington, USA Paul Spirakis, Computer Technology Institute, Patras, Greece ********************************************************* Publicity Co-Chairs Kwan-Wu Chin, Motorola, Sydney, Australia Sotiris Nikoletseas, Computer Technology Institute, Patras, Greece ********************************************************* IMPORTANT DATES: October 30, 2000 Workshop Paper Due December 10, 2000 Notification of Acceptance/Rejection January 15, 2001 Camera-Ready Paper Due Mobile computing has emerged as an important area of computing today as we move to the next millennium. This has been made possible due to the tremendous and continued growth of wireless communications and network technology over the past decade, providing infrastructures for "anytime anywhere" access to distributed computing systems and information repositories. The mobility of users offers new challenges to seamless connectivity in a distributed, heterogeneous network of wireline and wireless components. Several techniques and algorithms developed by the parallel and distributed computing community can be applied to solve typical wireless networks and mobile computing: routing, scheduling, load balancing, cache coherence, information access, and QoS provisioning problems. The objective of this workshop is to bring together technologists and researchers of international reputation in the areas of Parallel and Distributed Computing and Wireless Networks and Mobile Computing in order to have a forum for discussions, exchange of ideas and presentations. Authors are invited to submit original unpublished manuscripts for this workshop. Accepted papers will be published in the proceedings (by IEEE CS Press) of the IPDPS workshops. Topics of interest include (but are not limited to): * Processor Architectures for Mobile and Wearable Computers * Wireless networks in grid computing applications * Routing in adhoc networks * Parallel and distributed techniques for solving problems in mobile computing * Distributed techniques for QoS Provisioning in wireless networks * Distributed caches in mobile computing environments * Caching, prefetching, pushcaching and replication to enhance information access in wireless networks * Distributed wireless sensor networks * Routing and location independent information access * Scheduling issues in mobile computing * Parallel/distributed algorithms for mobile computing systems * Distributed Wireless multimedia systems * Active Networks SUBMISSION GUIDELINES: Authors are invited to submit summaries of original unpublished research to one of the Workshop Chairs. All submissions will be reviewed by referees. Summaries should not exceed ten (10) single-spaced pages of text using 12-point size type on 8.5 x 11 inch pages. References, figures, tables, etc. may be included in addition to the ten pages of text. The summary should include an abstract of approximately 100 words. The corresponding author is requested to include in a cover letter: (1) complete postal address; (2) email address; and (3) Phone/fax numbers. **************************************************************************** *************** Submissions may be by hard copy or by email. Electronic submissions are preferred and should be sent to kumar@cs.curtin.edu.au or spirakis@cti.gr. Authors should submit the cover page in ASCII form followed by a PostScript (level 2) file and make sure that it will print on a PostScript printer that uses 8.5 x 11 inch (US letter size) paper. For hard copy submissions, authors should submit seven (7) hard copies of their paper along with the cover letter to Mohan Kumar or Paul Spirakis. All manuscripts will be reviewed. Manuscripts must be received by October 30, 2000. Submissions received after the due date or exceeding the length limit may not be considered. Notification of review decisions will be mailed by December 10, 2000. Camera-ready papers are due January 15, 2001. Proceedings will be available at the Conference. Workshop Program Co-Chairs Mohan Kumar School of Computer Science Curtin University of Technology GPO Box U 1987, Perth WA 1987 AUSTRALIA Fax: +61 8 9266 2819 E-mail: kumar@cs.curtin.edu.au Paul Spirakis Director and Senior Researcher Computer Technology Institute 61 Riga Fereou Str., 26221 Patras, Greece Patras, Greece Fax: +30 61 993 973, +30 61 222086 E-mail: spirakis@cti.gr ++++++++++++++++++++++++++++++++++++++++ Technical Program Committee Somprakash Bandopadhyay, PWC Global, Calcutta, India Stefano Basagni, University of Texas at Dallas, USA Maurizio Bonuccelli University of Pisa, Italy Azzedine Boukerche, University of North Texas, USA Luca Cardelli, Microsoft Research, Cambridge, UK Kwan-Wu Chin, Motorola Australia Kee Chaing Chua, National University of Singapore Marco Conti, Italian National Research Council, Italy Samir Das, University of Cincinatti, USA Xiaohua Jia, City University of Hong Kong Jan van Leeuwen University of Utrecht, The Netherlands John Lui, The Chinese University of Hong Kong Marios Mavronicolas, University of Cyprus, Cyprus Sotiris Nikoletseas, Computer Technology Institute, Greece Cristina Pinnotti, Italian National Research Council Don Sannella University of Edinburgh, Scotland Martha Steenstrup, BBN Technologies, USA Mukesh Singhal, Ohio State University, USA Nitin Vaidya, Texas A&M University, USA Jie Wu, Florida Atlantic University, USA Yongbing Zhang University of Tsukuba, Japan Albert Zomaya University of Western Australia, Perth Australia ---------------------------------------------------------------------------- -------------------- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 12:56:31 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13304 for ; Mon, 23 Oct 2000 12:56:30 -0400 (EDT) Received: from standards (47.234.32.16:4677) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9438@standards.nortelnetworks.com>; Mon, 23 Oct 2000 12:39:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 40690 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 12:39:13 -0400 Received: from news.comp.lancs.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9436@standards.nortelnetworks.com>; Mon, 23 Oct 2000 12:39:12 -0400 Received: from SPOCK (egcsky000002.lancs.ac.uk [148.88.155.83]) by news.comp.lancs.ac.uk (8.10.2/8.10.2) with SMTP id e9NGt3h01833; Mon, 23 Oct 2000 17:55:03 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Approved-By: Stefan Schmid Message-ID: Date: Mon, 23 Oct 2000 17:51:42 +0100 Reply-To: Stefan Schmid Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Stefan Schmid Subject: Re: [MOBILE-IP] New version of "MobilitySupport in IPv6" draft X-To: vijayd@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <39F213DF.B2223DF7@iprg.nokia.com> Content-Transfer-Encoding: 7bit > On the Mobile Node side > > Before AH checksum calculation switch the contents of the source > address of > the packet and the Home Address dest option (the source address > would be CoA > already). This way the CoA is also protected. It seems you aggree with Charlie in that the CoA should be used for the AH calculation. Or did I get you wrong? > On the CN / Home Agent side > > 1. Process IPv6 header. > 2. Process Home Address option. Do the switch. Store the CoA in the Home > Address option. Maybe use a bit to indicate this. > 3. Process AH naturally. Security Association is chosen based on > the source address of the packet. If so, this does not make sense to me. If you do the "switch" (swapping CoA with HA) before the AH processing, you could not process the AH naturally (which would assume the CoA to be in the IPv6 SrcAddr field). Anyway, I agree with you that the best place to do the "switch" is when the Home Address option is processed. However, this implies that the AH calculation needs to use the CoA in the Home Address Option as IPv6 SrcAddr. This shouldn't be a problem though. > 4. Process BU. Only this module needs to know that the CoA is store in the > Home Address option. > 5. Call each protocol handler. Regards, - Stefan From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 13:14: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 NAA16374 for ; Mon, 23 Oct 2000 13:14:53 -0400 (EDT) Received: from standards (47.234.32.16:4677) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA94A6@standards.nortelnetworks.com>; Mon, 23 Oct 2000 12:59:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 40829 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 12:59:10 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA94A4@standards.nortelnetworks.com>; Mon, 23 Oct 2000 12:59:10 -0400 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 KAA08539; Mon, 23 Oct 2000 10:14:35 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9NHEWR09989; Mon, 23 Oct 2000 10:14:32 -0700 X-Virus-Scanned: Mon, 23 Oct 2000 10:14:32 -0700 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) smtpdckAnje; Mon, 23 Oct 2000 10:14:29 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: vijayd@IPRG.NOKIA.COM Message-ID: <39F471F7.8C44DF35@iprg.nokia.com> Date: Mon, 23 Oct 2000 10:14:31 -0700 Reply-To: Vijay Devarapalli Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Vijay Devarapalli Subject: Re: [MOBILE-IP] New version of "MobilitySupport in IPv6" draft X-To: Stefan Schmid To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit hi Stefan, see my comments below Stefan Schmid wrote: > > On the Mobile Node side > > > > Before AH checksum calculation switch the contents of the source > > address of > > the packet and the Home Address dest option (the source address > > would be CoA > > already). This way the CoA is also protected. > > It seems you aggree with Charlie in that the CoA should be used for the AH > calculation. Or did I get you wrong? > Well, it is a bit different. The CoA is protected by AH. But the AH module uses the IPv6 source address (after the switch, the source address contains the Home address) for choosing the security association. > On the CN / Home Agent side > > > > 1. Process IPv6 header. > > 2. Process Home Address option. Do the switch. Store the CoA in the Home > > Address option. Maybe use a bit to indicate this. > > 3. Process AH naturally. Security Association is chosen based on > > the source address of the packet. > > If so, this does not make sense to me. If you do the "switch" (swapping > CoA with HA) before the AH processing, you could not process the AH > naturally (which would assume the CoA to be in the IPv6 SrcAddr field). > The AH module need not assume anything. It can just go ahead, choose the security association based on the IPv6 source address and calculate the checksum over the packet. It need not bother about the contents in the Home Address destination option. Hope that clarifies things a bit Regards Vijay From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 13:26: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 NAA17813 for ; Mon, 23 Oct 2000 13:26:22 -0400 (EDT) Received: from standards (47.234.32.16:4677) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA94D8@standards.nortelnetworks.com>; Mon, 23 Oct 2000 13:04:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 40892 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 13:04:11 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA94D5@standards.nortelnetworks.com>; Mon, 23 Oct 2000 13:04:10 -0400 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 KAA09162; Mon, 23 Oct 2000 10:19:36 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9NHJYf17045; Mon, 23 Oct 2000 10:19:34 -0700 X-Virus-Scanned: Mon, 23 Oct 2000 10:19:34 -0700 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) smtpdP8nQnh; Mon, 23 Oct 2000 10:19:29 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: charliep@IPRG.NOKIA.COM Message-ID: <39F47322.D5FE2483@iprg.nokia.com> Date: Mon, 23 Oct 2000 10:19:30 -0700 Reply-To: "Charles E. Perkins" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] New version of "MobilitySupport in IPv6" draft X-To: Stefan Schmid To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Stefan, > > Before AH checksum calculation switch the contents of the source > > address of > > the packet and the Home Address dest option (the source address > > would be CoA > > already). This way the CoA is also protected. > > It seems you aggree with Charlie in that the CoA should be used for the AH > calculation. Or did I get you wrong? If you mean that the care-of address should be part of the data included as input to the AH calculation, I agree. However, the security association used to perform the calculation MUST be indexed by the mobile node's home address. > > On the CN / Home Agent side > > > > 1. Process IPv6 header. > > 2. Process Home Address option. Do the switch. Store the CoA in the Home > > Address option. Maybe use a bit to indicate this. > > 3. Process AH naturally. Security Association is chosen based on > > the source address of the packet. > > If so, this does not make sense to me. If you do the "switch" (swapping > CoA with HA) before the AH processing, you could not process the AH > naturally (which would assume the CoA to be in the IPv6 SrcAddr field). This procedure has the home address in the ip6_src address field before AH processing begins. So, AH processing is natural. > Anyway, I agree with you that the best place to do the "switch" is when > the Home Address option is processed. However, this implies that the AH > calculation needs to use the CoA in the Home Address Option as IPv6 SrcAddr. > This shouldn't be a problem though. It is a problem, because then the security association would have to be renegotiated every time the mobile node moves to a new care-of address. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 13:31: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 NAA18433 for ; Mon, 23 Oct 2000 13:31:44 -0400 (EDT) Received: from standards (47.234.32.16:4677) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA956C@standards.nortelnetworks.com>; Mon, 23 Oct 2000 13:11:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41077 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 13:11:36 -0400 Received: from qhars002.nortel.com (47.101.112.102:54667) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA956A@standards.nortelnetworks.com>; Mon, 23 Oct 2000 13:11:35 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Mon, 23 Oct 2000 18:26:38 +0100 Received: from zrchs148 by smtprch1.nortel.com; Mon, 23 Oct 2000 11:49:49 -0500 Received: from zrchb200.us.nortel.com (actually zrchb200) by zrchs148; Mon, 23 Oct 2000 11:42:01 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id <4VMD1X99>; Mon, 23 Oct 2000 11:49:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03D11.366B8B90" Approved-By: Ron Young Message-ID: Date: Mon, 23 Oct 2000 11:49:30 -0500 Reply-To: Ron Young Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ron Young Subject: [MOBILE-IP] Testing something To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM ------_=_NextPart_001_01C03D11.366B8B90 Content-type: text/plain; charset="iso-8859-1" Just letting everyone know that I am testing a semi-moderated setting on our mailing list. This setting allows anyone subscribed to the list to post, but anyone who is not subscribed must have their post approved by the editor (me). We'll see how well this works. ------------------------------------------------------------------------ Ron Young ronyoung@nortelnetworks.com http://www.nortelnetworks.com/ You can't spell Nortel without Ron; of course, you can't spell moron without Ron either. ------_=_NextPart_001_01C03D11.366B8B90 Content-type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Testing something

Just letting everyone know that I am testing a = semi-moderated setting on our mailing list.  This setting allows = anyone subscribed to the list to post, but anyone who is not subscribed = must have their post approved by the editor (me).  We'll see how = well this works.

---------------------------------------------------------------= ---------
Ron Young   = ronyoung@nortelnetworks.com   http://www.nortelnetworks.com/
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;          
  You can't spell Nortel without Ron; of = course, you can't spell moron
          &nb= sp;           &nb= sp;    without Ron either.
 

------_=_NextPart_001_01C03D11.366B8B90-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 13:38: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 NAA19269 for ; Mon, 23 Oct 2000 13:38:26 -0400 (EDT) Received: from standards (47.234.32.16:4677) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA95C2@standards.nortelnetworks.com>; Mon, 23 Oct 2000 13:17:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41182 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 13:17:34 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA95C0@standards.nortelnetworks.com>; Mon, 23 Oct 2000 13:17:34 -0400 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 KAA10294; Mon, 23 Oct 2000 10:32:59 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9NHWvX29006; Mon, 23 Oct 2000 10:32:57 -0700 X-Virus-Scanned: Mon, 23 Oct 2000 10:32:57 -0700 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) smtpdVhVbsP; Mon, 23 Oct 2000 10:32:54 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <39DB6C48.8D2BE6E2@iprg.nokia.com> <39F213DF.B2223DF7@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: charliep@IPRG.NOKIA.COM Message-ID: <39F47647.CE0A588C@iprg.nokia.com> Date: Mon, 23 Oct 2000 10:32:55 -0700 Reply-To: "Charles E. Perkins" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySupport in IPv6"draft] X-To: Vijay Devarapalli To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello folks, I understand better now the implementation difficulties which are caused by leaving the care-of address in the IPv6 header. So, I agree with you that we should specify the behavior you have suggested below, which also is much closer to the spirit of the existing Internet Draft specification. I'll use the word "exchange" instead of "switch", since the latter was misinterpreted in at least one implementation effort. I hope this is acceptable, and I am also looking for additional comments before the next revision is completed. Regards, Charlie P. Vijay Devarapalli wrote: > > Hi Charlie. > > see my comments below > > "Charles E. Perkins" wrote: > > > Hello folks, > > > > I would like to mandate (i.e., MUST) the simplest possible > > strategy, to wit: > > > > 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. > > > > Of course, this also means that the node receiving a packet > > with AH will have to follow the same algorithm, which > > basically just means not moving data fields at all. > > The only complication comes when it is necessary to look up > > the appropriate security association for processing either > > AH or ESP. That lookup, typically indexed by the > > Source IP address of the IPv6 header, would instead have > > to be indexed by the home address in the Home Address > > destination option. Since that destination option would > > occur in the packet _before_ the security header, > > processing is still very simple. > > > > This makes the implementation of the ip_input function difficult for those > packets which carry the Home Address option before the AH. In particular, I > wouldnt know when to exactly replace the CoA with the Home address in the > source of the packet. > > Consider the case where a CN/Home Agent receives a BU. The packet could be > like this > > IPv6 header, HA dest hdr, AH, BU dest hdr, TCP hdr. > > The ip_input() function most often is a protocol switch which just calls the > corresponding protocol handler for each protocol header that it encounters. > I need to replace the CoA with home address before I give it to the module > which handles TCP. I have three options > > 1. do the switch in the BU handling function > 2. do the switch in ip_input function before calling the upper layer > functions > 3. do the switch in the tcp module. > > Consider another case where the packet is > > IPv6 header, HA dest hdr, ICMP > > Now I have two options > > 1. do the switch in ip_input function before calling the upper layer > functions > 2. do the switch in the ICMP module > > Yet another case could be > > IPv6 hdr, HA dest hdr, Frag hdr, AH, BU, ICMP > > In this case I would have to do the switch before the frag header is > processed. Now both the AH module and the BU handler need to be aware for > this. > > Therefore the best and the easiest thing to do would be do the switch when > the HA dest hdr is processed. Then AH proceeds normally. The BU handler alone > needs to know where the CoA is stored (could be a pointer / in the HA dest > hdr after the switch) > > I would like to propose the following. > > On the Mobile Node side > > Before AH checksum calculation switch the contents of the source address of > the packet and the Home Address dest option (the source address would be CoA > already). This way the CoA is also protected. This switch is not a big deal > because, most oftenAH implementation would require creating another text > string or mbuf(with mutable fields zeroed out). The checksum is calculated on > this text string. The original mbuf is left intact. > > On the CN / Home Agent side > > 1. Process IPv6 header. > 2. Process Home Address option. Do the switch. Store the CoA in the Home > Address option. Maybe use a bit to indicate this. > 3. Process AH naturally. Security Association is chosen based on the source > address of the packet. > 4. Process BU. Only this module needs to know that the CoA is store in the > Home Address option. > 5. Call each protocol handler. > > In my opinion, the above makes things easy to implement. Comments are > welcome. > > Regards > Vijay From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 13:57: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 NAA22903 for ; Mon, 23 Oct 2000 13:57:53 -0400 (EDT) Received: from standards (47.234.32.16:4677) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA96A5@standards.nortelnetworks.com>; Mon, 23 Oct 2000 13:40:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41467 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 13:40:25 -0400 Received: from news.comp.lancs.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA96A3@standards.nortelnetworks.com>; Mon, 23 Oct 2000 13:40:25 -0400 Received: from SPOCK (egcsky000002.lancs.ac.uk [148.88.155.83]) by news.comp.lancs.ac.uk (8.10.2/8.10.2) with SMTP id e9NHuNh02570 for ; Mon, 23 Oct 2000 18:56:23 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Approved-By: Stefan Schmid Message-ID: Date: Mon, 23 Oct 2000 18:53:02 +0100 Reply-To: Stefan Schmid Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Stefan Schmid Subject: [MOBILE-IP] FW: [MOBILE-IP] New version of "MobilitySupport in IPv6" draft To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit > If you mean that the care-of address should be part of the data > included as input to the AH calculation, I agree. Yep, that's what I meant. > However, the security association used to perform the calculation > MUST be indexed by the mobile node's home address. Absolutely ... But the address used for the selection of the security association is "independent" of the address used in the AH calculation. Therefore using the CoA in the AH calculation and the Home Address for the SA selection is no problem. - Stefan From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 18:09: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 SAA01628 for ; Mon, 23 Oct 2000 18:09:41 -0400 (EDT) Received: from standards (47.234.32.16:3611) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA98FA@standards.nortelnetworks.com>; Mon, 23 Oct 2000 17:52:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 42239 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 17:52:19 -0400 Received: from smtp-2.hut.fi by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA98E2@standards.nortelnetworks.com>; Mon, 23 Oct 2000 17:42:17 -0400 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 AAA83799; Tue, 24 Oct 2000 00:57:39 +0300 (EEST) 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.20001023104432.0068c9bc@era-t.ericsson.se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Approved-By: tom@SMTP.HUT.FI Message-ID: <39F4B45C.87DC28F5@cc.hut.fi> Date: Tue, 24 Oct 2000 00:57:48 +0300 Reply-To: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" Organization: HUT Subject: Re: [MOBILE-IP] WG LastCall-(draft-ietf-mobileip-reg-tunnel-03.txt) X-To: Annika Jonsson To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Annika Thanks for your reply. I am working on a more detailed "review" on the last call draft. I am sorry for waking up so late to this issue. I discovered the 'hidden' assumption of RFAs and their GFA knowing abouit each other from the draft. :-) I will check the security association issue more closely. I am not completely convinced that there needs to be a separate message type for different uses of security associations. Why couldn't the FAs automatically consider the registration as a home reg if there is not acceptable sec association used for FA-MN authentication? I will send my comment later. Hopefully not too late. :-/ When does the last call end? Regards, Tom Annika Jonsson wrote: > > Hi Tom, > > see comments below. > > At 23:55 2000-10-21 +0300, Tom K. Weckström wrote: > >Hi, > > > >In my opinion, additional messages makes the protocol partly clearer, > >but partly more complex. > > > >Here are my questions (please point me to the appropriate messages, if > >these questions have already been discussed :) > > > >- Is it possible/needed that a FA does not know the GFA or GFAs above > >it? > >I think FAs and GFAs should have trust relationships = knowledge of > >each other. > > Yes, FA:s and GFA:s need to know about each other. That is also stated in > the draft (well, indirectly, since it says that they need to have > established security associations between them). > > > > >- Why do we need to add intelligence to the mobile node? > >Having a totally transparent hierarchy is possible. The MN would speak > >standard RFC2002 MIP and would still get the best efficiency in > >registrations through the regionalized handoffs. By defining new > >messages we do add intelligence to MN. It must know what kind of > >registrations to send. > > > > Because, as I said in my last mail, the MN needs to know if the > registration request will be processed in the home or in the visited domain > to know which security association and replay protection to use. We didn't > find any way to get around this. But another goal is to support RFC2002 > MN:s also. In this draft, they don't get the benefits of the regional > registrations, but they will work. > > /Annika > > >And my totally subjective opinion: > > ;-) > >Despite the lively discussion about regionalized handoffs etc., I > >still have not seen many transparent, fast and *implemented* > >approaches. If the ideas in the drafts have been implemented, please > >provide the community some links to the material. Dynamics - HUT > >Mobile IP has been rocking for 1.5 years now. Dynamics is transparent > >to the Mobile Node and still provides fast handoffs. > > > >Should we write a competing draft? ;-) We didn't do it in the first > >place because we felt it would just slow down the fast handoff design > >process. Unfortunately the process has been unbelievably slow. I am > >really looking forward to a solution in this issue. > > > >Regards, > > Tom > > > >-- > > Tom Weckström Dynamics group > > Helsinki University of Technology > > dynamics@cs.hut.fi > > > >http://www.cs.hut.fi/Research/Dynamics/ > > > > > >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). > >> > >> 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" > >> To: > >> 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 > >> > > > >> > > > -- 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 Mon Oct 23 18:21: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 SAA02942 for ; Mon, 23 Oct 2000 18:21:11 -0400 (EDT) Received: from standards (47.234.32.16:3611) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9962@standards.nortelnetworks.com>; Mon, 23 Oct 2000 18:03:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 42410 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 18:03:51 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9960@standards.nortelnetworks.com>; Mon, 23 Oct 2000 18:03:50 -0400 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 PAA14791; Mon, 23 Oct 2000 15:17:32 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9NMHUJ04543; Mon, 23 Oct 2000 15:17:30 -0700 X-Virus-Scanned: Mon, 23 Oct 2000 15:17:30 -0700 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) smtpdvLkqDD; Mon, 23 Oct 2000 15:17:18 PDT X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <3.0.32.20001023104432.0068c9bc@era-t.ericsson.se> <39F4B45C.87DC28F5@cc.hut.fi> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Approved-By: Charlie Perkins Message-ID: <39F4B895.C718AE7D@iprg.nokia.com> Date: Mon, 23 Oct 2000 15:15:50 -0700 Reply-To: Charlie Perkins Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Charlie Perkins Organization: Nokia Subject: Re: [MOBILE-IP] WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt) X-To: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" X-cc: Annika Jonsson To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hello Tom, > I discovered the 'hidden' assumption of RFAs and their GFA knowing > abouit each other from the draft. :-) It wasn't intended to be hidden. How can we make it more explicit? > I will check the security association issue more closely. > I am not completely convinced that there needs to be a separate > message type for different uses of security associations. > Why couldn't the FAs automatically consider the registration as a home > reg if there is not acceptable sec association used for FA-MN > authentication? Because the mobile node is very likely to want to send a home registration whenever it feels like renewing its current care-of address, thereby increasing the lifetime. We do not want to make any implicit judgements about type of registration based on the remaining registratoin lifetime. That sounds like a really bad idea. At any time, the mobile node should be allowed to send either a home registration or a regional registration, subject only to the constraint that the lifetime of the regional registration should not exceed the lifetime of the regional registration. > I will send my comment later. > Hopefully not too late. :-/ > When does the last call end? I think formally it might have ended a month ago, but the purpose after all is to find out if the draft is ready for advancement. So, I think it's just fine to ask questions. So far, the main comments we have gotten about necessary changes is to put in more details about running in the mode where the "first" foreign agent becomes the GFA (what others have called "anchoring"). Other than that, I think we're ready to go depending on your comments. Regards, Charlie P. Annika Jonsson wrote: > > > > Hi Tom, > > > > see comments below. > > > > At 23:55 2000-10-21 +0300, Tom K. Weckström wrote: > > >Hi, > > > > > >In my opinion, additional messages makes the protocol partly clearer, > > >but partly more complex. > > > > > >Here are my questions (please point me to the appropriate messages, if > > >these questions have already been discussed :) > > > > > >- Is it possible/needed that a FA does not know the GFA or GFAs above > > >it? > > >I think FAs and GFAs should have trust relationships = knowledge of > > >each other. > > > > Yes, FA:s and GFA:s need to know about each other. That is also stated in > > the draft (well, indirectly, since it says that they need to have > > established security associations between them). > > > > > > > >- Why do we need to add intelligence to the mobile node? > > >Having a totally transparent hierarchy is possible. The MN would speak > > >standard RFC2002 MIP and would still get the best efficiency in > > >registrations through the regionalized handoffs. By defining new > > >messages we do add intelligence to MN. It must know what kind of > > >registrations to send. > > > > > > > Because, as I said in my last mail, the MN needs to know if the > > registration request will be processed in the home or in the visited domain > > to know which security association and replay protection to use. We didn't > > find any way to get around this. But another goal is to support RFC2002 > > MN:s also. In this draft, they don't get the benefits of the regional > > registrations, but they will work. > > > > /Annika > > > > >And my totally subjective opinion: > > > ;-) > > >Despite the lively discussion about regionalized handoffs etc., I > > >still have not seen many transparent, fast and *implemented* > > >approaches. If the ideas in the drafts have been implemented, please > > >provide the community some links to the material. Dynamics - HUT > > >Mobile IP has been rocking for 1.5 years now. Dynamics is transparent > > >to the Mobile Node and still provides fast handoffs. > > > > > >Should we write a competing draft? ;-) We didn't do it in the first > > >place because we felt it would just slow down the fast handoff design > > >process. Unfortunately the process has been unbelievably slow. I am > > >really looking forward to a solution in this issue. > > > > > >Regards, > > > Tom > > > > > >-- > > > Tom Weckström Dynamics group > > > Helsinki University of Technology > > > dynamics@cs.hut.fi > > > > > >http://www.cs.hut.fi/Research/Dynamics/ > > > > > > > > >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). > > >> > > >> 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" > > >> To: > > >> 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 > > >> > > > > >> > > > > > > -- > 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 Tue Oct 24 19: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 TAA26867 for ; Tue, 24 Oct 2000 19:14:37 -0400 (EDT) Received: from standards (47.234.32.16:3973) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA236@standards.nortelnetworks.com>; Tue, 24 Oct 2000 18:56:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45254 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 24 Oct 2000 18:56:45 -0400 Received: from smtp-2.hut.fi by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA234@standards.nortelnetworks.com>; Tue, 24 Oct 2000 18:46:44 -0400 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 CAA23205; Wed, 25 Oct 2000 02:02:08 +0300 (EEST) 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.20001023104432.0068c9bc@era-t.ericsson.se> <39F4B45C.87DC28F5@cc.hut.fi> <39F4B895.C718AE7D@iprg.nokia.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Approved-By: tom@SMTP.HUT.FI Message-ID: <39F614FB.11918DBB@cc.hut.fi> Date: Wed, 25 Oct 2000 02:02:19 +0300 Reply-To: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" Organization: HUT Subject: Re: [MOBILE-IP] WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt) X-To: Charlie Perkins X-cc: Annika Jonsson To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hello Charlie, Here comes my lengthy comments about reg-tunnel-03. Sorry for a long email, but there were lots of things to comment. I hope the ASCII graphics is not distorted. I found quite many issues. Some of them might be possible to solve with more explanations (maybe I just did not get the ideas). Some of the issues should be solved in other ways. More ideas below. Read on. Regards, Tom COMMENTS TO draft-ietf-mobileip-reg-tunnel-03.txt Tom Weckström Legend: + = A positive note - = A negative note, criticism ? = A question ! = Exclamation, either a critical issue or an important suggestion idea --> = conclusion mark Ch 1. + Decision power at MN: regional or home registration possible ? Is it always good to let the MN deicde what kind of registration to use? ? What are the benefits in giving the MN the right to decide? - Different registration types makes the protocol more complex - Changes to std RFC2002 MN - Changes to FAs Ch 3.1 ? Is there a possibility to make a HA hierarchy as well? If not, why then? --> Possibly another draft. Could be derived from J.K.Malinen's thesis. 3.1.1. ? Why only assume two levels of FAs in the visited domain? ? Is the protocol fully flexible in its current form to support N-level hierarchies? It should be. More comments after Appendix B. "We assume that there exist established security associations between a GFA and the regional foreign agents beneath it." ---> This implies the RFAs HAVE to know their GFA. ---> Satwant Kaur's scenario with RFA not knowing the GFA is impossible. ---> No need for different message types for regional and home registration. ---> More transparency and simpleness achieved. 3.3. " If the `I' bit is set, there MUST be at least one care-of address in the Agent Advertisement message." "If the `I' bit is set, and there is only one care-of address, it is the address of the GFA." ---> If so, there cannot be a situation where GFA is not known at the moment of registration. (Provided the address is real, not zero.) ---> The text could be clarified to mention about the relationships of the FAs in the hierarchy. Do they all know each other? Do they only know who's above and who's below them?. 3.4.1. + Setting GFA IP to zero improves flexibility. "If the `I' bit is set, but the GFA address is zero (0), the mobile node MUST check to make sure that it receives a GFA IP address extension as part of any home registration, or else send its home registration using the care-of address of some previously known GFA in the same visited domain." ? This makes the possible topologies more cumbersome. ---> Eg. GFA1, ..., GFA4 are all connected to RFA1 and RFA2 and RFA3 and RFA4. ? Why is this needed? For load balancing type of activities? ? Does the possibility to set GFA address to zero in the request open new holes in the security? E.g. Mallory acts as an additional GFA in the hierarchy and captures MN's reg.reg. coming from RFA1. This gives a possibility to intrude as a GFA into MIP signaling. However, additional bonuses are few. And eventually Mallory could set up his own ISP. 3.4.2. " If the care-of address field is set to zero, the foreign agent assigns a GFA to the mobile node, by some means not described in this specification, and adds a GFA IP Address extension to the Registration Request message." ? RFA selects the GFA? RFA has no knowledge of GFA conditions (load, etc.). How could an RFA make the decision? This could be solved with the topology or by other means, but involves more protocol intelligence anyway and whence adds to complexity. "and it SHOULD be protected by an FA-FA Authentication extension." ? Where is FA-FA auth ext described? In another draft, I suppose. 3.5.1. " it is necessary to distinguish regional registrations from home registration. Thus, we introduce new message types for the Regional Registration messages." ? Could we make the distinction by defining that every registration with a valid MN-FA auth ext is a regional registration? Furthermore, if there is no MN-FA auth ext or if that extension is invalid, the FAs forward the message upwards in the hierarchy. Example: Consider an N-level hierarchy. See image below: ------ | HA | ------ | (Internet) | ------- | GFA | ------- / \ ------- ------- | FA1 | | FA2 | ------- ------- / \ / \ ------- ------- ------- ------- | FA3 | | FA4 | | FA5 | | FA6 | ------- ------- ------- ------- \ \ ------ | MN | ------ Figure 1: Mobility Agent Hierarchy ! Now, if MN is registered to FA4 and changes to FA6, then it sends the registration request to FA6 and FA6 does not know the MN-FA auth ext in the registration neither has it heard of MN before (no mobility bindings existing for MN). Then FA6 jsut forwards the request upwards to FA2. FA2 also does not have a clue about MN, so it too forwards the request upwards. Finally, GFA knows the MN from its bindings and also can validate the MN-FA auth ext. Eventually, this registration became regional. Now, if there were no MN-FA auth ext, or if it was invalid, also the GFA would have forwarded the message - now to the HA. Maybe an invalid auth extensions should result in request denial if the MN is known to the FA (i.e. there is a binding for the MN in the FA). After all the MN is known, and the authentication does not match. ! Anyway, there seems to be no need for separate regional and home registration messages. The MN still has the choice to either include the FA-MN auth ext or leave it away. ! NOTE, that this is directly applicable to N-level hierarchies! 3.5.2. " The only difference is that there is the GFA IP address instead of the address of the home agent." ? Does this mean that the Home Agent field in the RFC2002 compliant registration request field has the IP addr of GFA? Section 6.1. verified this assumption. This could be more clearly stated already in section 3.5.2. 4.2. "By comparing the domain part of the foreign agent NAI with the domain part of its own NAI, the mobile node can determine whether it is in its home domain or in a visited domain, and whether it has changed domain since it last registered." + Exactly! Good. :) 6.1. " GFA IP Address The IP address of the Gateway Foreign Agent. (Replaces Home Agent field in Registration Request message in [9].) Care-of Address Care-of address of local foreign agent; MAY be set to zero. " ? Why should the HA field be replaced? There is the COA field to be used for the GFA IP addr. The FAs in the hierarchy can use extensions or directly the source IP of the outer header to get the address of the "lower" agent in the hierarchy as the registration traverses upwards. ? Why is the COA field filled with the local COA? The lowest FA always knows behind which interface the MN is. The FA aboe the lowest FA knows the interface from which the first reg.request came and also the IP of the lowest FA. This continues from the bottom of the FA tree to the top, i.e., the GFA. ALL that is needed in MIP sense is the GFA IP in the COA field and this is for the HA. The hierarchy of FAs handles the tunneling in the hierarhcy by other means. A. " - 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;" ! Dynamics works with nonces also, and it supports regional registrations. I have to find out how the nonce synchronization is done in Dynamics. Perhaps the lack of FA-MN auth ext (again) is enough for the MN to control between home and regional registrations. B.2. " This process is repeated in each RFA in the hierarchy, until an RFA recognizes the mobile node as already registered. This RFA may be the GFA, or any RFA beneath it in the hierarchy. If the mobile node is already registered with this RFA, the RFA generates a Regional Registration Reply and sends it to the next lower-level RFA in the hierarchy. The lifetime field in the Regional Registration Reply is set to the remaining lifetime that was earlier agreed upon between the mobile node and the GFA. If the lifetime of the GFA registration has expired, the Regional Registration Request is relayed all the way to the GFA. If the hierarchy between the advertising foreign agent and the GFA is announced in the Agent Advertisement, the mobile node may generate a Regional Registration Request not destined to the GFA, but to the closest RFA with which it can register. " ? So, if the FA hierarchy is not revealed in the advertisements, then the regional registrations always go to the GFA? ! There are drawbacks with this approach: - The hierarchy is not transparent anymore --> A security issue --> Needs more functionality in MN - The advertisements become some bytes larger because of the hierarchy information in them. - IF the hierarchy is not revealed, then the GFA is loaded because of ALL the regional registrations coming to it. --> SUGGESTION: ! Make the MN add a "previous FA NAI" extension to its registrations intended for regional handling. See more info from Jouni Malinen's thesis (p. 29-30) available on Dynamics HUT MIP web site. This removes the rece condition inherent in for example Dynamics v. 0.5 which used specific tear down messages. This also keeps the hierarhcy completely transparent and does NOT require any complex intelligence from the MN, e.g. to claculate the closest "common" RFA that could be the target for a regional registration. Adding the previous FA NAI extension is very straightforward and does not require any additional intelligence from the MN. B.2.1. " recognizes the mobile node as already registered, may generate a Regional Registration Reply, not all Regional Registration Requests will reach the GFA. Therefore, if old locations are not deregistered, it is possible that tunnels are not correctly redirected when a mobile node moves back to a previous foreign agent." ! I think Jouni Malinen solved this issue in his thesis, too. The solution is tied to the "previous FA NAI extension". Jouni's thesis, pages 29-30 at least, clarify this solution. " In case (3), the mobile node sends a Regional Registration Request to its new foreign agent. If the mobile node does not request smooth handoff, the previous foreign agent is not notified. The Regional Registration Request is relayed upwards in the hierarchy until it reaches a foreign agent that recognizes the mobile node as already registered. This foreign agent generates a Regional Registration Reply and sends it downwards in the hierarchy toward the new location of the mobile node, updating its own visitor list. At the same time, it also sends a Binding Update with a zero lifetime to the previous care-of address it had registered for the mobile node. The Binding Update is authenticated by the FA-FA Authentication extension. Each foreign agent receiving the Binding Update removes the mobile node from its visitor lists. The Binding Update is relayed down to the care-of address of the mobile node known to that foreign agent, and each foreign agent in the hierarchy receiving this notification removes the mobile node from its visitor list. " ! This results in the race condition I mentioned before. Dynamics v 0.5 had similar kind of message with zero binding lifetime. We called this a "tear down" message, because it tore down the old bindings and tunnels. There is a race condition in this, when for example tear down messages are lost. The state of the FA hierarchy is not up to date a fter one missed tear down message. Use "previous FA NAI" extension instead. This, too, has a possible problem, also mentioned in Jouni's thesis, if the reg.reply is lost and MN moves forward to another FA that may think it can actually answer the request. This can be soved as in Jouni's thesis or by only using the NAI of that FA from which we previously have received a positive reg.reply.... " If the mobile node uses a co-located care-of address for its regional registration, there is no need to deregister its previous location when it moves, since regional registrations with a co-located care-of address are performed directly with the GFA." ! I would say this is a limitation of your architecture. The GFA MUST NOT be automatically burdened by this kind of registrations. If this is not fixed, then we lose a part of the whole idea of using hierarchies - to distribute and localize the registration handling as much as possible. Charlie Perkins wrote: > > Hello Tom, > > > I discovered the 'hidden' assumption of RFAs and their GFA knowing > > abouit each other from the draft. :-) > > It wasn't intended to be hidden. How can we make it more explicit? > > > I will check the security association issue more closely. > > I am not completely convinced that there needs to be a separate > > message type for different uses of security associations. > > Why couldn't the FAs automatically consider the registration as a home > > reg if there is not acceptable sec association used for FA-MN > > authentication? > > Because the mobile node is very likely to want to send a home > registration whenever it feels like renewing its current care-of > address, thereby increasing the lifetime. We do not want to make > any implicit judgements about type of registration based on the > remaining registratoin lifetime. That sounds like a really bad idea. > > At any time, the mobile node should be allowed to send either a > home registration or a regional registration, subject only to the > constraint that the lifetime of the regional registration should not > exceed the lifetime of the regional registration. > > > I will send my comment later. > > Hopefully not too late. :-/ > > When does the last call end? > > I think formally it might have ended a month ago, but the purpose > after all is to find out if the draft is ready for advancement. So, > I think it's just fine to ask questions. So far, the main comments > we have gotten about necessary changes is to put in more details > about running in the mode where the "first" foreign agent becomes > the GFA (what others have called "anchoring"). > > Other than that, I think we're ready to go depending on your > comments. > > Regards, > Charlie P. -- Tom Weckström Dynamics group Helsinki University of Technology dynamics@cs.hut.fi http://www.cs.hut.fi/Research/Dynamics/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Oct 25 10:25: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 KAA11763 for ; Wed, 25 Oct 2000 10:25:07 -0400 (EDT) Received: from standards (47.234.32.16:4350) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA673@standards.nortelnetworks.com>; Wed, 25 Oct 2000 10:07:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 46660 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 25 Oct 2000 10:07:27 -0400 Received: from rzcomm4.rz.tu-bs.de by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA671@standards.nortelnetworks.com>; Wed, 25 Oct 2000 10:07:26 -0400 Received: from bnj5wkvnahwovb (ppp420.ts.rz.tu-bs.de [134.169.241.171]) by rzcomm4.rz.tu-bs.de (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id QAA20922 for ; Wed, 25 Oct 2000 16:22:51 +0200 (METDST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C03EA0.095F1690" 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.2919.6700 Approved-By: Belhassen Jerbi Message-ID: Date: Wed, 25 Oct 2000 16:24:23 +0200 Reply-To: Belhassen Jerbi Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Belhassen Jerbi Subject: [MOBILE-IP] Unsubscribe To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C03EA0.095F1690 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thanks. Belhassen Jerbi. ------=_NextPart_000_0000_01C03EA0.095F1690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks.

Belhassen = Jerbi.

------=_NextPart_000_0000_01C03EA0.095F1690-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 26 05:00: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 FAA17220 for ; Thu, 26 Oct 2000 05:00:41 -0400 (EDT) Received: from standards (47.234.32.16:4157) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAAE4F@standards.nortelnetworks.com>; Thu, 26 Oct 2000 4:42:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 49206 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 26 Oct 2000 04:42:53 -0400 Received: from smtp4s.retemail.es (smtp4s.iddeo.es) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAAE4D@standards.nortelnetworks.com>; Thu, 26 Oct 2000 4:42:53 -0400 Received: from zipi ([62.81.29.130]) by smtp4s.retemail.es (InterMail vM.4.01.02.00 201-229-116) with SMTP id <20001026085826.GQGO58679.smtp4s.retemail.es@zipi> for ; Thu, 26 Oct 2000 10:58:26 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C03F3B.AD6BAFF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Approved-By: Oscar de Luis Message-ID: <001001c03f33$4df074a0$821d513e@CATALUNYA> Date: Thu, 26 Oct 2000 10:58:30 +0100 Reply-To: Oscar de Luis Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Oscar de Luis Subject: [MOBILE-IP] Unsubscribe To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C03F3B.AD6BAFF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you=20 OSCAR DE LUIS ------=_NextPart_000_000D_01C03F3B.AD6BAFF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thank you
 
OSCAR DE = LUIS
------=_NextPart_000_000D_01C03F3B.AD6BAFF0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 26 08:28: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 IAA18826 for ; Thu, 26 Oct 2000 08:28:47 -0400 (EDT) Received: from standards (47.234.32.16:4201) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAAFCD@standards.nortelnetworks.com>; Thu, 26 Oct 2000 8:11:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 49641 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 26 Oct 2000 08:10:59 -0400 Received: from qhars002.nortel.com (47.101.112.102:55706) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAAFCB@standards.nortelnetworks.com>; Thu, 26 Oct 2000 8:10:59 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Thu, 26 Oct 2000 13:26:04 +0100 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Thu, 26 Oct 2000 07:24:06 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id <4VMDH2NQ>; Thu, 26 Oct 2000 07:24:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03F47.A098A4C0" Approved-By: Ron Young Message-ID: Date: Thu, 26 Oct 2000 07:24:03 -0500 Reply-To: Ron Young Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ron Young Subject: [MOBILE-IP] FW: [MOBILE-IP] WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt ) 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_01C03F47.A098A4C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Annika Jonsson [mailto:annika.jonsson@ericsson.com] Sent: Thursday, October 26, 2000 3:58 AM To: "Tom K. Weckstr=F6m"; Charlie Perkins Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt) ------------------ Hi Tom, I'll try to answer your comments and questions. This mail only deals = with the simple ones, more will follow in separate messages... At 02:02 2000-10-25 +0300, Tom K. Weckstr=F6m wrote: > > >Hello Charlie, > >Here comes my lengthy comments about reg-tunnel-03. Sorry for a long >email, but there were lots of things to comment. >I hope the ASCII graphics is not distorted. >I found quite many issues. >Some of them might be possible to solve with more explanations (maybe >I just did not get the ideas). Some of the issues should be solved in >other ways. More ideas below. Read on. > >Regards, > Tom > > >COMMENTS TO draft-ietf-mobileip-reg-tunnel-03.txt > >Tom Weckstr=F6m > >Legend: >+ =3D A positive note >- =3D A negative note, criticism >? =3D A question >! =3D Exclamation, either a critical issue or an important suggestion >idea >--> =3D conclusion mark > > >Ch 3.1 >? Is there a possibility to make a HA hierarchy as well? > If not, why then? >--> Possibly another draft. Could be derived from J.K.Malinen's >thesis. > Sure it is, it was included in one of the predecessors to this draft. = We felt it would be easier to handle it in separate drafts, and we think = the hierarchical FA:s are more important. >3.1.1. >? Why only assume two levels of FAs in the visited domain? > It's mainly for pedagogic reasons. It makes the description of the = protocol easier and clearer, and also we think that is an important scenario. In this way we first describe the basics of the protocol, and then add the multiple level hierarchies. >? Is the protocol fully flexible in its current form to support >N-level hierarchies? It should be. More comments after Appendix B. > It's supposed to be. If not, we would certainly want to know ;-) I'll = look at your comments after teh Appendix. >3.3. > >" If the `I' bit is set, there MUST be at least one care-of address in >the Agent Advertisement message." >"If the `I' bit is set, and there is only one care-of address, it is > the address of the GFA." >---> If so, there cannot be a situation where GFA is not known at the > moment of registration. (Provided the address is real, not zero.) > The GFA address in the advertisments can be zero. Will clarify this. >---> The text could be clarified to mention about the relationships of > the FAs in the hierarchy. Do they all know each other? Do they > only know who's above and who's below them?. > Yes, this should be clarified. > >3.4.1. > >+ Setting GFA IP to zero improves flexibility. > >"If the `I' bit is set, but the GFA > address is zero (0), the mobile node MUST check to make sure that >it > receives a GFA IP address extension as part of any home >registration, > or else send its home registration using the care-of address of >some > previously known GFA in the same visited domain." > >? This makes the possible topologies more cumbersome. >---> Eg. GFA1, ..., GFA4 are all connected to RFA1 and RFA2 and RFA3 >and RFA4. >? Why is this needed? For load balancing type of activities? > Yes, we wanted to allow this kind of topology. It can be used for e.g. = load balancing, or, it could be that an MN should use a specific GFA for different reasons. >? Does the possibility to set GFA address to zero in the request open >new holes in the security? E.g. Mallory acts as an additional GFA in >the hierarchy and captures MN's reg.reg. coming from RFA1. This gives >a possibility to intrude as a GFA into MIP signaling. However, >additional bonuses are few. And eventually Mallory could set up his >own ISP. > No, when the reply comes back to the RFA, the FA-FA auth. will fail in = that case. >3.4.2. > >" If the care-of address field is set to zero, the foreign agent > assigns a GFA to the mobile node, by some means not described in > this specification, and adds a GFA IP Address extension to the > Registration Request message." > >? RFA selects the GFA? RFA has no knowledge of GFA conditions (load, >etc.). How could an RFA make the decision? This could be solved with >the topology or by other means, but involves more protocol >intelligence anyway and whence adds to complexity. > We specificaly said: "by some means not described in this = specification". It's not necessarily the RFA that decides, but it must have some way = of finding out which GFA to use, of course.=20 > >"and it SHOULD be protected by an FA-FA Authentication extension." >? Where is FA-FA auth ext described? In another draft, I suppose. > Oohps, will add that. >3.5.2. > >" The only difference is that there is the GFA IP address instead of > the address of the home agent." > >? Does this mean that the Home Agent field in the RFC2002 compliant >registration request field has the IP addr of GFA? Section >6.1. verified this assumption. This could be more clearly stated >already in section 3.5.2. > > Will clarify. > >B.2. >" > This process is repeated in each RFA in the hierarchy, until an RFA > recognizes the mobile node as already registered. This RFA may be > the GFA, or any RFA beneath it in the hierarchy. If the mobile >node > is already registered with this RFA, the RFA generates a Regional > Registration Reply and sends it to the next lower-level RFA in the > hierarchy. The lifetime field in the Regional Registration Reply >is > set to the remaining lifetime that was earlier agreed upon between > the mobile node and the GFA. If the lifetime of the GFA >registration > has expired, the Regional Registration Request is relayed all the >way > to the GFA. > > If the hierarchy between the advertising foreign agent and the GFA >is > announced in the Agent Advertisement, the mobile node may generate > a Regional Registration Request not destined to the GFA, but to the > closest RFA with which it can register. >" > >? So, if the FA hierarchy is not revealed in the advertisements, then >the regional registrations always go to the GFA? > No. See your quotation above, the first RFA that recognises the MN = replies (unless the lifetime has expired). This is regardless of whether hierarchies are advertised or not. I'll come back to your other comments later. Thanks for your feedback! /Annika ------_=_NextPart_001_01C03F47.A098A4C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: [MOBILE-IP] = WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt)

-----Original Message-----
From: Annika Jonsson [mailto:annika.jonsson@ericss= on.com]
Sent: Thursday, October 26, 2000 3:58 AM
To: "Tom K. Weckstr=F6m"; Charlie = Perkins
Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MOBILE-IP]
WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt)


This  message was  originally = submitted  by annika.jonsson@ERICSSON.COM  to the
MOBILE-IP list at  = STANDARDS.NORTELNETWORKS.COM. If you simply  forward it = back
to the  list, using a  mail command = that  generates "Resent-" fields  (ask your
local user  support or  consult the  = documentation of your  mail program  if in
doubt), it will be distributed and the explanations = you are now reading will be
removed automatically.  If on  the = other  hand you  edit the  contributions you
receive  into a  digest,  you  = will have  to  remove  this paragraph  = manually.
Finally, you should be able to contact  the = author of this message by using the
normal "reply" function of your mail = program.

---------------- Message requiring your approval (194 = lines) ------------------
Hi Tom,

I'll try to answer your comments and questions. This = mail only deals with
the simple ones, more will follow in separate = messages...

At 02:02 2000-10-25 +0300, Tom K. Weckstr=F6m = wrote:
>
>
>Hello Charlie,
>
>Here comes my lengthy comments about = reg-tunnel-03. Sorry for a long
>email, but there were lots of things to = comment.
>I hope the ASCII graphics is not = distorted.
>I found quite many issues.
>Some of them might be possible to solve with = more explanations (maybe
>I just did not get the ideas). Some of the = issues should be solved in
>other ways. More ideas below. Read on.
>
>Regards,
>       Tom
>
>
>COMMENTS TO = draft-ietf-mobileip-reg-tunnel-03.txt
>
>Tom Weckstr=F6m
>
>Legend:
>+ =3D A positive note
>- =3D A negative note, criticism
>? =3D A question
>! =3D Exclamation, either a critical issue or an = important suggestion
>idea
>--> =3D conclusion mark
>

>
>Ch 3.1
>? Is there a possibility to make a HA hierarchy = as well?
>  If not, why then?
>--> Possibly another draft. Could be derived = from J.K.Malinen's
>thesis.
>

Sure it is, it was included in one of the = predecessors to this draft. We
felt it would be easier to handle it in separate = drafts, and we think the
hierarchical FA:s are more important.

>3.1.1.
>? Why only assume two levels of FAs in the = visited domain?
>

It's mainly for pedagogic reasons. It makes the = description of the protocol
easier and clearer, and also we think that is an = important scenario. In
this way we first describe the basics of the = protocol, and then add the
multiple level hierarchies.

>? Is the protocol fully flexible in its current = form to support
>N-level hierarchies? It should be. More comments = after Appendix B.
>

It's supposed to be. If not, we would certainly want = to know ;-) I'll look
at your comments after teh Appendix.


>3.3.
>
>" If the `I' bit is set, there MUST be at = least one care-of address in
>the Agent Advertisement message."
>"If the `I' bit is set, and there is only = one care-of address, it is
>   the address of the = GFA."
>---> If so, there cannot be a situation where = GFA is not known at the
>     moment of registration. = (Provided the address is real, not zero.)
>

The GFA address in the advertisments can be zero. = Will clarify this.

>---> The text could be clarified to mention = about the relationships of
>     the FAs in the = hierarchy. Do they all know each other? Do they
>     only know who's above = and who's below them?.
>

Yes, this should be clarified.

>
>3.4.1.
>
>+ Setting GFA IP to zero improves = flexibility.
>
>"If the `I' bit is set, but the GFA
>   address is zero (0), the mobile = node MUST check to make sure that
>it
>   receives a GFA IP address extension = as part of any home
>registration,
>   or else send its home registration = using the care-of address of
>some
>   previously known GFA in the same = visited domain."
>
>? This makes the possible topologies more = cumbersome.
>---> Eg. GFA1, ..., GFA4 are all connected to = RFA1 and RFA2 and RFA3
>and RFA4.
>? Why is this needed? For load balancing type of = activities?
>

Yes, we wanted to allow this kind of topology. It can = be used for e.g. load
balancing, or, it could be that an MN should use a = specific GFA for
different reasons.

>? Does the possibility to set GFA address to zero = in the request open
>new holes in the security?  E.g. Mallory = acts as an additional GFA in
>the hierarchy and captures MN's reg.reg. coming = from RFA1. This gives
>a possibility to intrude as a GFA into MIP = signaling. However,
>additional bonuses are few. And eventually = Mallory could set up his
>own ISP.
>

No, when the reply comes back to the RFA, the FA-FA = auth. will fail in that
case.

>3.4.2.
>
>" If the care-of address field is set to = zero, the foreign agent
>   assigns a GFA to the mobile node, = by some means not described in
>   this specification, and adds a GFA = IP Address extension to the
>   Registration Request = message."
>
>? RFA selects the GFA? RFA has no knowledge of = GFA conditions (load,
>etc.). How could an RFA make the decision? This = could be solved with
>the topology or by other means, but involves = more protocol
>intelligence anyway and whence adds to = complexity.
>

We specificaly said: "by some means not = described in this specification".
It's  not necessarily the RFA that decides, but = it must have some way of
finding out which GFA to use, of course.

>
>"and it SHOULD be protected by an FA-FA = Authentication extension."
>? Where is FA-FA auth ext described? In another = draft, I suppose.
>

Oohps, will add that.


>3.5.2.
>
>" The only difference is that there is the = GFA IP address instead of
>   the address of the home = agent."
>
>? Does this mean that the Home Agent field in = the RFC2002 compliant
>registration request field has the IP addr of = GFA? Section
>6.1. verified this assumption. This could be = more clearly stated
>already in section 3.5.2.
>
>

Will clarify.

>
>B.2.
>"
> This process is repeated in each RFA in the = hierarchy, until an RFA
>   recognizes the mobile node as = already registered.  This RFA may be
>   the GFA, or any RFA beneath it in = the hierarchy.  If the mobile
>node
>   is already registered with this = RFA, the RFA generates a Regional
>   Registration Reply and sends it to = the next lower-level RFA in the
>   hierarchy.  The lifetime field = in the Regional Registration Reply
>is
>   set to the remaining lifetime that = was earlier agreed upon between
>   the mobile node and the GFA. If the = lifetime of the GFA
>registration
>   has expired, the Regional = Registration Request is relayed all the
>way
>   to the GFA.
>
>   If the hierarchy between the = advertising foreign agent and the GFA
>is
>   announced in the Agent = Advertisement, the mobile node may generate
>   a Regional Registration Request not = destined to the GFA, but to the
>   closest RFA with which it can = register.
>"
>
>? So, if the FA hierarchy is not revealed in the = advertisements, then
>the regional registrations always go to the = GFA?
>

No. See your quotation above, the first RFA that = recognises the MN replies
(unless the lifetime has expired). This is = regardless of whether
hierarchies are advertised or not.

I'll come back to your other comments later.

Thanks for your feedback!
/Annika

------_=_NextPart_001_01C03F47.A098A4C0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 26 08:28: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 IAA18844 for ; Thu, 26 Oct 2000 08:28:48 -0400 (EDT) Received: from standards (47.234.32.16:4201) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAAFDD@standards.nortelnetworks.com>; Thu, 26 Oct 2000 8:12:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 49659 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 26 Oct 2000 08:11:59 -0400 Received: from qhars002.nortel.com (47.101.112.102:55811) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAAFDB@standards.nortelnetworks.com>; Thu, 26 Oct 2000 8:11:59 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Thu, 26 Oct 2000 13:27:19 +0100 Received: from zrchs148 by smtprch1.nortel.com; Thu, 26 Oct 2000 07:26:36 -0500 Received: from zrchb200.us.nortel.com (actually zrchb200) by zrchs148; Thu, 26 Oct 2000 07:18:57 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id <4VMDH233>; Thu, 26 Oct 2000 07:26:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03F47.F8E04890" Approved-By: Ron Young Message-ID: Date: Thu, 26 Oct 2000 07:26:31 -0500 Reply-To: Ron Young Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ron Young Subject: [MOBILE-IP] FW: DATELINE EXTENSION: IPDPS-2001 Workshop on PDC Issues in WNMC To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM ------_=_NextPart_001_01C03F47.F8E04890 Content-type: text/plain; charset="iso-8859-1" -----Original Message----- From: Kwan-Wu Chin [mailto:kwchin@arc.corp.mot.com] Sent: Thursday, October 26, 2000 1:27 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: DATELINE EXTENSION: IPDPS-2001 Workshop on PDC Issues in WNMC ------------------ Dear Collegues, Sorry if you received multiple copies of this CFP. Dateline Extended: ** 10th November 2000 ** Cheers Kwan Motorola Australia Research Centre (MARC) ------------------------------- CFP ------------------------------ 1st International Workshop on Parallel and Distributed Computing Issues in Wireless Networks and Mobile Computing IPDPS 2001 WORKSHOPS April 23-27, 2001 Hyatt Regency San Francisco Airport ******************************************************************* General Chair Sajal K. Das, The University of Texas at Arlington, USA Program Co-Chairs Mohan J. Kumar, Curtin University of Technology, Perth, Australia and The University of Texas at Arlington, USA Paul Spirakis, Computer Technology Institute, Patras, Greece ********************************************************************* Mobile computing has emerged as an important area of computing today as we move to the next millennium. This has been made possible due to the tremendous and continued growth of wireless communications and network technology over the past decade, providing infrastructures for "anytime anywhere" access to distributed computing systems and information repositories. The mobility of users offers new challenges to seamless connectivity in a distributed, heterogeneous network of wireline and wireless components. Several techniques and algorithms developed by the parallel and distributed computing community can be applied to solve typical wireless networks and mobile computing : routing, scheduling, load balancing, cache coherence, information access, and QoS provisioning problems. The objective of this workshop is to bring together technologists and researchers of international reputation in the areas of Parallel and Distributed Computing and Wireless Networks and Mobile Computing in order to have a forum for discussions, exchange of ideas and presentations. Authors are invited to submit original unpublished manuscripts for for this workshop. Accepted papers will be published in the proceedings of the IPDPS workshops Topics of interest include (but are not limited to): * Processor Architectures for Mobile and Wearable Computers * Wireless networks in grid computing applications * Routing in adhoc networks * Parallel and distributed techniques for solving problems in mobile computing * Distributed techniques for QoS Provisioning in wireless networks * Distributed caches in mobile computing environments * Caching, prefetching, pushcaching and replication to enhance information access in wireless networks * Distributed wireless sensor networks * Routing and location independent information access * Scheduling issues in mobile computing * Parallel/distributed algorithms for mobile computing systems * Distributed Wireless multimedia systems * Active Networks SUBMISSION GUIDELINES: Authors are invited to submit summaries of original unpublished research to one opf the the Workshop Chairs. All submissions will be reviewed by referees. Summaries should not exceed ten (10) single-spaced pages of text using 12 point size type on 8.5 x 11 inch pages. References, figures, tables, etc. may be included in addition to the ten pages of text. The summary should include an abstract of approximately 100 words. The corresponding author is requested to include in a cover letter: (1) complete postal address; (2) email address; (3) phone number; and (4) fax number. Submissions may be by hard copy or by email. Electronic submissions are preferred and should be sent to kumar@cs.curtin.edu.au or spirakis@cti.gr. Authors should submit the cover page in ASCII form followed by a PostScript (level 2) file and make sure that it will print on a PostScript printer that uses 8.5 x 11 inch (US letter size) paper. For hard copy submissions, authors should submit seven (7) hard copies of their paper along with the cover letter to Mohan Kumar or Paul Spirakis. All manuscripts will be reviewed. Manuscripts must be received by October 30, 2000. Submissions received after the due date or exceeding the length limit may not be considered. Notification of review decisions will be mailed by December 10, 2000. Camera-ready papers are due January 15, 2001. Proceedings will be available at the Conference. ********************************************************************* IMPORTANT DATES: November 10, 2000 Workshop Paper Due (Extended) December 10, 2000 Notification of Acceptance/Rejection January 15, 2001 Camera-Ready Paper Due ********************************************************************* Workshop Program Co-Chairs Mohan Kumar School of Computer Science Curtin University of Technology GPO Box U 1987, Perth WA 1987 AUSTRALIA Fax: +61 8 9266 2819 E-mail: kumar@cs.curtin.edu.au and Paul Spirakis Director and Senior Researcher Computer Technology Institute 61 Riga Fereou Str., 26221 Patras, Greece Patras, Greece Fax: +30 61 993 973, +30 61 222086 E-mail: spirakis@cti.gr ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Technical Program Committee ------------------------------ Maurizio Bonuccelli University of Pisa, Italy Azzedine Boukerche, University of North Texas, USA Luca Cardelli, Microsoft Research, Cambridge, UK Kwan-Wu Chin, Motorola Australia Research Centre Kee Chaing Chua, National University of Singapore Marco Conti, Italian National Research Council, Italy Samir Das, University of Cincinatti, USA Xiaohua Jia, City University of Hong Kong Jan van Leeuwen University of Utrecht, The Netherlands John Lui, The Chinese University of Hong Kong Marios Mavronicolas, University of Cyprus, Cyprus Cristina Pinnotti, Italian National Research Council Sotiris Nikoletseas Computer Technology Institute, Greece Don Sannella University of Edinburgh, Scotland Mukesh Singhal, Ohio State University, USA Nitin Vaidya, Texas A&M University, USA Yongbing Zhang University of Tsukuba, Japan Martha Steenstrup, BBN Technologies, USA Albert Zomaya, University of Western Australia, Perth, Australia Somprakash Bandopadhyay, PWC Global, Calcutta, India Stefano Basagni, University of Texas at Dallas, USA Steering Commitee (Under creation) ------------------------------ Victor Bahl, Microsoft, Seattle, USA Kalyan Basu, Nortel Networks, Richardson, USA Andrew Campbell, Columbia University, USA Imrich Chlamtac, The University of Texas at Dallas Sajal Das, The University of Texas at Arlington, USA Publicity Co-Chairs: ------------------------------ Kwan-Wu Chin, Motorola Australia Research Centre Sotiris Nikoletseas Computer Technology Institute ------_=_NextPart_001_01C03F47.F8E04890 Content-type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: DATELINE EXTENSION: IPDPS-2001 Workshop on PDC Issues in = WNMC

-----Original Message-----
From: Kwan-Wu Chin [mailto:kwchin@arc.corp.mot.com]
Sent: Thursday, October 26, 2000 1:27 AM
To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject: DATELINE EXTENSION: IPDPS-2001 Workshop on = PDC Issues in WNMC


This  message  was  originally  = submitted  by  kwchin@ARC.CORP.MOT.COM  to  = the
MOBILE-IP list at  = STANDARDS.NORTELNETWORKS.COM. If you simply  forward it = back
to the  list, using a  mail command = that  generates "Resent-" fields  (ask your
local user  support or  consult the  = documentation of your  mail program  if in
doubt), it will be distributed and the explanations = you are now reading will be
removed automatically.  If on  the = other  hand you  edit the  contributions you
receive  into a  digest,  you  = will have  to  remove  this paragraph  = manually.
Finally, you should be able to contact  the = author of this message by using the
normal "reply" function of your mail = program.

---------------- Message requiring your approval (154 = lines) ------------------
Dear Collegues,

  Sorry if you received multiple copies of = this
CFP. 

Dateline Extended: ** 10th November 2000 **

Cheers
Kwan
Motorola Australia Research Centre (MARC)

------------------------------- CFP = ------------------------------
          &nb= sp;         1st  = International Workshop on
          &nb= sp;        Parallel and Distributed = Computing
          &nb= sp;          Issues in = Wireless Networks and
          &nb= sp;           &nb= sp;    Mobile Computing

IPDPS 2001 WORKSHOPS
April 23-27, 2001
Hyatt Regency
San Francisco Airport
***************************************************************= ****
General Chair
Sajal K. Das, The University of Texas at Arlington, = USA

Program  Co-Chairs
Mohan J. Kumar, Curtin University of Technology, = Perth, Australia
          &nb= sp;     and The University of Texas at  = Arlington, USA
Paul Spirakis, Computer Technology Institute, = Patras, Greece
***************************************************************= ******
Mobile computing has emerged as an important area of = computing today as
we move to the next millennium. This has been made = possible due to the
tremendous and continued growth of wireless = communications and network
technology over the past decade, providing = infrastructures for "anytime
anywhere" access to distributed computing = systems and information
repositories. The mobility of users offers new = challenges to seamless
connectivity in a distributed, heterogeneous network = of wireline and
wireless components.  Several techniques and = algorithms developed by the
parallel and distributed computing community can be = applied to solve
typical  wireless networks and  mobile = computing : routing, scheduling,
load balancing, cache coherence, information access, = and QoS
provisioning problems. The objective of this = workshop is to bring
together technologists and researchers of = international reputation in
the areas of Parallel and Distributed Computing and = Wireless Networks
and Mobile Computing in order to have a forum = for  discussions, exchange
of ideas  and presentations.
Authors are invited to submit original unpublished = manuscripts for for
this workshop. Accepted papers will be published in = the proceedings of
the IPDPS workshops

Topics of interest include (but are not limited = to):
* Processor Architectures for Mobile and Wearable = Computers
* Wireless networks in grid computing = applications
* Routing in adhoc networks
* Parallel and distributed techniques for solving = problems in mobile
  computing
* Distributed techniques for QoS Provisioning in = wireless networks
* Distributed caches in mobile computing = environments
* Caching, prefetching, pushcaching and replication = to enhance
  information access in wireless = networks
* Distributed wireless sensor networks
* Routing and location independent information = access
* Scheduling issues in mobile computing
* Parallel/distributed algorithms for mobile = computing systems
* Distributed Wireless multimedia systems
* Active Networks


SUBMISSION GUIDELINES:
Authors are invited to submit summaries of original = unpublished research
to one opf the the Workshop Chairs.  All = submissions will be reviewed by
referees. Summaries should not exceed ten  (10) = single-spaced pages of
text using 12 point size type on 8.5 x 11 inch = pages. References,
figures, tables, etc. may be included in addition to = the ten  pages of
text. The summary should include an abstract of = approximately 100
words.  The corresponding author is requested = to include in a cover
letter: (1) complete postal address; (2) email = address; (3) phone
number; and (4) fax number. Submissions may be by = hard copy or by
email.  Electronic submissions are preferred = and should be sent to
kumar@cs.curtin.edu.au or spirakis@cti.gr. Authors = should submit the
cover page in ASCII form followed by a PostScript = (level 2) file and
make sure that it will print on a PostScript printer = that uses 8.5 x 11
inch (US letter size) paper.  For hard copy = submissions, authors should
submit seven (7) hard copies of their paper along = with the cover letter
to Mohan Kumar or Paul Spirakis.
All  manuscripts  will be reviewed.  = Manuscripts   must be received by
October 30, 2000.  Submissions received after = the  due date or exceeding
the  length    limit may = not  be    considered. Notification of = review
decisions will be mailed by December 10, 2000. = Camera-ready papers are
due January  15, 2001.  Proceedings = will  be available at the
Conference.
***************************************************************= ******
IMPORTANT DATES:
November 10,  = 2000         Workshop Paper Due = (Extended)
December 10,  = 2000         Notification of = Acceptance/Rejection
January  15,  = 2001         Camera-Ready Paper = Due
***************************************************************= ******
Workshop Program Co-Chairs
Mohan Kumar
School of Computer Science
Curtin University of Technology
GPO Box U 1987, Perth WA 1987
AUSTRALIA
Fax: +61 8 9266 2819
E-mail: kumar@cs.curtin.edu.au

and

Paul Spirakis
Director and Senior Researcher
Computer Technology Institute
61 Riga Fereou Str., 26221 Patras, Greece
Patras, Greece
Fax: +30 61 993 973, +30 61 222086
E-mail: spirakis@cti.gr
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= +
Technical Program Committee
------------------------------

Maurizio Bonuccelli University of Pisa, Italy
Azzedine Boukerche, University of North Texas, = USA
Luca Cardelli, Microsoft Research, Cambridge, = UK
Kwan-Wu Chin, Motorola Australia Research = Centre
Kee Chaing Chua, National University of = Singapore
Marco Conti, Italian National Research Council, = Italy
Samir Das, University of Cincinatti, USA
Xiaohua Jia, City University of Hong Kong
Jan van Leeuwen University of Utrecht, The = Netherlands
John Lui, The Chinese University of Hong Kong
Marios Mavronicolas, University of Cyprus, = Cyprus
Cristina Pinnotti, Italian National Research = Council
Sotiris Nikoletseas Computer Technology Institute, = Greece
Don Sannella  University of Edinburgh, = Scotland
Mukesh Singhal, Ohio State University, USA
Nitin Vaidya, Texas A&M University, USA
Yongbing Zhang  University of Tsukuba, = Japan
Martha Steenstrup, BBN Technologies, USA
Albert Zomaya, University of Western Australia, = Perth, Australia
Somprakash Bandopadhyay, PWC Global, Calcutta, = India
Stefano Basagni, University of Texas at Dallas, = USA


Steering Commitee (Under creation)
------------------------------
Victor Bahl, Microsoft, Seattle, USA
Kalyan Basu, Nortel Networks, Richardson, USA
Andrew Campbell, Columbia University, USA
Imrich Chlamtac, The University of Texas at = Dallas
Sajal Das, The University of Texas at Arlington, = USA

Publicity Co-Chairs:
------------------------------
Kwan-Wu Chin, Motorola Australia Research = Centre
Sotiris Nikoletseas Computer Technology = Institute

------_=_NextPart_001_01C03F47.F8E04890-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 26 08:45: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 IAA24427 for ; Thu, 26 Oct 2000 08:45:22 -0400 (EDT) Received: from standards (47.234.32.16:4201) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAB0B8@standards.nortelnetworks.com>; Thu, 26 Oct 2000 8:27:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 49932 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 26 Oct 2000 08:27:49 -0400 Received: from qhars002.nortel.com (47.101.112.102:57392) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAB0B6@standards.nortelnetworks.com>; Thu, 26 Oct 2000 8:27:49 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Thu, 26 Oct 2000 13:42:09 +0100 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Thu, 26 Oct 2000 07:41:47 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id <4VMDH2V5>; Thu, 26 Oct 2000 07:41:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03F4A.19458490" Approved-By: Ron Young Message-ID: Date: Thu, 26 Oct 2000 07:41:45 -0500 Reply-To: Ron Young Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ron Young Subject: [MOBILE-IP] FW: question about Mobility Support in IPv6 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_01C03F4A.19458490 Content-Type: text/plain; charset="big5" -----Original Message----- From: jcliu@itri.org.tw [mailto:jcliu@itri.org.tw] Sent: Thursday, October 26, 2000 1:16 AM To: MOBILE-IP Subject: question about Mobility Support in IPv6 I have a question about establishing forwarding from a previous care-of-address (10.9 in draft-ietf-mobileip-ipv6-12.txt). I know this section describes how to forward packet as mobile node from a foreign network to another foreign network. In MIPv4, the previous foreign agent can buffer packets and send to mobile node as mobile node move to another foreign. This operatio can delete packets loss. But in MIPv6, there is no foreign agent. The MIPv6 draft said "the mobile node sends a Binding Update to any home agent on the link on which the previous care-of-address is located, indicating this previous acre-of-address as the home address for the binding" Assumption in hard handoff situation, the home agent in the above descrition can buffer packets and send to mobile node as like foreign agent in MIPv4?? But maybe before 1 second, correspending node send packets directly to mobile node. after 1 second, the mobile node moves from the foreign network to another foreign network. Who can buufer these packets during 1 second?? I am confuse about this operation during movement betwork foreign networks. ------_=_NextPart_001_01C03F4A.19458490 Content-Type: text/html; charset="big5"
-----Original Message-----
From: jcliu@itri.org.tw [mailto:jcliu@itri.org.tw]
Sent: Thursday, October 26, 2000 1:16 AM
To: MOBILE-IP
Subject: question about Mobility Support in IPv6

I have a question about establishing forwarding from a previous care-of-address (10.9 in draft-ietf-mobileip-ipv6-12.txt).
I know this section describes how to forward packet as mobile node from a foreign network to another foreign network.
 
In MIPv4, the previous foreign agent can buffer packets and send to  mobile node as mobile node move to another foreign. This operatio can delete packets loss.
But in MIPv6, there is no foreign agent.
The MIPv6 draft said "the mobile node sends a Binding Update to any home agent on the link on which the previous care-of-address is located, indicating this previous acre-of-address as the home address for the binding"
Assumption in hard handoff situation, the home agent in the above descrition can buffer packets and send to mobile node as like foreign agent in MIPv4??
But maybe before 1 second, correspending node send packets directly to mobile node.
after 1 second, the mobile node moves from the foreign network to another foreign network.
Who can buufer these packets during 1 second??
I am confuse about this operation during movement betwork foreign networks.
 
------_=_NextPart_001_01C03F4A.19458490-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 26 10:09: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 KAA16003 for ; Thu, 26 Oct 2000 10:09:07 -0400 (EDT) Received: from standards (47.234.32.16:4201) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAB28C@standards.nortelnetworks.com>; Thu, 26 Oct 2000 9:51:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 50500 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 26 Oct 2000 09:51:41 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAB28A@standards.nortelnetworks.com>; Thu, 26 Oct 2000 9:51:41 -0400 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 HAA15868; Thu, 26 Oct 2000 07:05:04 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9QE53M25807; Thu, 26 Oct 2000 07:05:03 -0700 X-Virus-Scanned: Thu, 26 Oct 2000 07:05:03 -0700 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) smtpdDnT5Lb; Thu, 26 Oct 2000 07:04:59 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: charliep@IPRG.NOKIA.COM Message-ID: <39F83A0C.6C63E155@iprg.nokia.com> Date: Thu, 26 Oct 2000 07:05:00 -0700 Reply-To: "Charles E. Perkins" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] FW: DATELINE EXTENSION: IPDPS-2001 Workshop on PDCIssues in WNMC X-To: Ron Young To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Ron, In this case, the cure has been far worse than the disease. Now, I cannot tell who sent the e-mail, and I can't select on that field. Moreover, I would rather not have to read through: > -----Original Message----- > From: Kwan-Wu Chin [mailto:kwchin@arc.corp.mot.com] > Sent: Thursday, October 26, 2000 1:27 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: DATELINE EXTENSION: IPDPS-2001 Workshop on PDC Issues in WNMC > > This message was originally submitted by kwchin@ARC.CORP.MOT.COM to > the > MOBILE-IP list at STANDARDS.NORTELNETWORKS.COM. If you simply forward it > back > to the list, using a mail command that generates "Resent-" fields (ask > your > local user support or consult the documentation of your mail program if > in > doubt), it will be distributed and the explanations you are now reading will > be > removed automatically. If on the other hand you edit the contributions > you > receive into a digest, you will have to remove this paragraph > manually. > Finally, you should be able to contact the author of this message by using > the > normal "reply" function of your mail program. > > ---------------- Message requiring your approval (154 lines) before I get to read anything of actual interest. I hope this can be fixed. I don't love spam, but it's far better than this alternative. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 26 10:16: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 KAA17559 for ; Thu, 26 Oct 2000 10:16:08 -0400 (EDT) Received: from standards (47.234.32.16:4201) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAB2E0@standards.nortelnetworks.com>; Thu, 26 Oct 2000 9:59:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 50610 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 26 Oct 2000 09:59:20 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAB2DE@standards.nortelnetworks.com>; Thu, 26 Oct 2000 9:59:20 -0400 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA12001; Thu, 26 Oct 2000 08:14:53 -0600 (MDT) 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 HAA25352; Thu, 26 Oct 2000 07:14:52 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA27463; Thu, 26 Oct 2000 07:14:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Approved-By: Patrice Calhoun Message-ID: Date: Thu, 26 Oct 2000 07:12:24 -0700 Reply-To: Patrice Calhoun Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Patrice Calhoun Subject: Re: [MOBILE-IP] FW: DATELINE EXTENSION: IPDPS-2001 Workshop on PDCIssues in WNMC X-To: "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <39F83A0C.6C63E155@iprg.nokia.com> There is unfortunately no real great solution to eliminating SPAM. On my mailing lists, I restrict postings to people that are subscribed to the list. Of course, the problem that we are seeing is that some people have subscribed using their aliases (e.g. pcalhoun@eng.sun.com, as opposed to pat.calhoun@eng.sun.com). Such people can no longer post, unless they change their subscription parameters on the list. So, I would propose the following: 1. Let messages bounce if the sender is not on the list. Do not forward such e-mails to the list yourself (it is rather confusing). It is agravating for the sender, but they'll get over it once they get their subscription changed. 2. Let the list members worry about changing their own subscription information. my 2 cents, PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 26 11:59: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 LAA10593 for ; Thu, 26 Oct 2000 11:59:22 -0400 (EDT) Received: from standards (47.234.32.16:1173) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAB3B8@standards.nortelnetworks.com>; Thu, 26 Oct 2000 11:41:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 50879 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 26 Oct 2000 11:41:42 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAB3B6@standards.nortelnetworks.com>; Thu, 26 Oct 2000 11:41:42 -0400 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 e9QFvFt00115; Thu, 26 Oct 2000 17:57:15 +0200 (MEST) Received: from e00105a2d1ed7 by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id RAA19035; Thu, 26 Oct 2000 17:57:14 +0200 X-Sender: erajoaa@era-t.ericsson.se X-Mailer: Windows Eudora Pro Version 3.0 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Approved-By: Annika Jonsson Message-ID: <3.0.32.20001026175546.00cd61a8@era-t.ericsson.se> Date: Thu, 26 Oct 2000 17:55:47 +0200 Reply-To: Annika Jonsson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Annika Jonsson Subject: Re: [MOBILE-IP] WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt) X-To: "=?iso-8859-1?Q?=22Tom_K._Weckstr=F6m=22?=" , Charlie Perkins To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA10593 Hello Tom, here is part two of my answer to your comments. (if you didn't see the first one, it's probably because I sent it from the wrong address, and it went via the moderator) These comments are all about the issue of different message types for regional registrations. Summary: I still think it's the best way. See my arguments below. /Annika At 02:02 2000-10-25 +0300, Tom K. Weckström wrote: > > >Hello Charlie, > >Here comes my lengthy comments about reg-tunnel-03. Sorry for a long >email, but there were lots of things to comment. >I hope the ASCII graphics is not distorted. >I found quite many issues. >Some of them might be possible to solve with more explanations (maybe >I just did not get the ideas). Some of the issues should be solved in >other ways. More ideas below. Read on. > >Regards, > Tom > > >COMMENTS TO draft-ietf-mobileip-reg-tunnel-03.txt > >Tom Weckström > >Legend: >+ = A positive note >- = A negative note, criticism >? = A question >! = Exclamation, either a critical issue or an important suggestion >idea >--> = conclusion mark > >Ch 1. >+ Decision power at MN: regional or home registration possible >? Is it always good to let the MN deicde what kind of registration to >use? >? What are the benefits in giving the MN the right to decide? > >- Different registration types makes the protocol more complex > - Changes to std RFC2002 MN > - Changes to FAs > It has nothing to do with benefits. As I see it it is a _necessity_ for the MN to know who will process the registration, the HA or an FA, because it needs to know what security association to use (I feel I am repeating myself;-). It is possible that it could be solved by having the MN add both the home and the visited authentication and both the home and the visited replay protection (in case of nounces), and then let the network take the actual decision, but that introduces even more complexity in the MN. >"We assume that there exist established > security associations between a GFA and the regional foreign > agents beneath it." >---> This implies the RFAs HAVE to know their GFA. >---> Satwant Kaur's scenario with RFA not knowing the GFA is >impossible. >---> No need for different message types for regional and home >registration. >---> More transparency and simpleness achieved. > You are right, but my example still holds! I will repeat it here: "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." >3.5.1. > >" it is necessary to distinguish regional registrations from home > registration. Thus, we introduce new message types for the > Regional Registration messages." > >? Could we make the distinction by defining that every registration >with a valid MN-FA auth ext is a regional registration? Furthermore, >if there is no MN-FA auth ext or if that extension is invalid, the FAs >forward the message upwards in the hierarchy. >Example: Consider an N-level hierarchy. See image below: > > ------ > | HA | > ------ > | > (Internet) > | > ------- > | GFA | > ------- > / \ > ------- ------- > | FA1 | | FA2 | > ------- ------- > / \ / \ > ------- ------- ------- ------- > | FA3 | | FA4 | | FA5 | | FA6 | > ------- ------- ------- ------- > \ > \ > ------ > | MN | > ------ > > Figure 1: Mobility Agent Hierarchy > > >! Now, if MN is registered to FA4 and changes to FA6, then it sends >the >registration request to FA6 and FA6 does not know the MN-FA auth ext >in the registration neither has it heard of MN before (no mobility >bindings existing for MN). Then FA6 jsut forwards the request upwards >to FA2. FA2 also does not have a clue about MN, so it too forwards the >request upwards. Finally, GFA knows the MN from its bindings and also >can validate the MN-FA auth ext. Eventually, this registration became >regional. Now, if there were no MN-FA auth ext, or if it was invalid, >also the GFA would have forwarded the message - now to the HA. Maybe >an invalid auth extensions should result in request denial if the MN >is known to the FA (i.e. there is a binding for the MN in the >FA). After all the MN is known, and the authentication does not match. > >! Anyway, there seems to be no need for separate regional and home >registration messages. The MN still has the choice to either include >the FA-MN auth ext or leave it away. > >! NOTE, that this is directly applicable to N-level hierarchies! > > I agree, it could be done in this way, but you still need a change to an RFC2002 MN, since it will always include the MN-FA auth. ext if it has an SA with the FA (that is mandatory). Secondly, one argument that persuaded us that different message types is a "cleaner" solution is that we didn't like the idea to use e.g. the auth. ext. to let an FA decide what it "thinks" that the MN wants. This is why: normally if the authentication fails, this error should be reported back to the MN and no registration be made. The authentication could fail for several reasons! It feels wrong, both "decisionwise" and "securitywise", to use this failure to authenticate the message as an indication of something that the MN wants the FA to do. > > >6.1. > > >" > GFA IP Address > The IP address of the Gateway Foreign Agent. (Replaces > Home Agent field in Registration Request message > in [9].) > > Care-of Address > Care-of address of local foreign agent; MAY be set to > zero. >" > >? Why should the HA field be replaced? There is the COA field to >be used for the GFA IP addr. The FAs in the hierarchy can use >extensions or directly the source IP of the outer header to get the >address of the "lower" agent in the hierarchy as the registration >traverses upwards. > >? Why is the COA field filled with the local COA? The lowest FA >always knows behind which interface the MN is. The FA aboe the lowest >FA knows the interface from which the first reg.request came and also >the IP of the lowest FA. This continues from the bottom of the FA tree >to the top, i.e., the GFA. ALL that is needed in MIP sense is the GFA >IP in the COA field and this is for the HA. The hierarchy of FAs >handles the tunneling in the hierarhcy by other means. > > Why use extensions when we don't have to? In a regional registration the HA address is not needed, so we reuse that field. Actually, the GFA kind of acts as a "local HA", so doing it in this way makes it very consistent with RFC2002. > > >A. > >" - 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;" > >! Dynamics works with nonces also, and it supports regional >registrations. I have to find out how the nonce synchronization is >done in Dynamics. Perhaps the lack of FA-MN auth ext (again) is enough >for the MN to control between home and regional registrations. > > It would be interesting to see your solution. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 26 13:26: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 NAA26546 for ; Thu, 26 Oct 2000 13:26:39 -0400 (EDT) Received: from standards (47.234.32.16:1173) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAB47C@standards.nortelnetworks.com>; Thu, 26 Oct 2000 13:08:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 51143 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 26 Oct 2000 13:08:57 -0400 Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAB47A@standards.nortelnetworks.com>; Thu, 26 Oct 2000 13:08:57 -0400 Received: from gopal.cisco.com (dhcp-171-70-61-178.cisco.com [171.70.61.178]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA04218; Thu, 26 Oct 2000 10:24:23 -0700 (PDT) X-Sender: gdommety@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Approved-By: Gopal Dommety Message-ID: <4.3.2.7.2.20001026101605.00b63d90@omega.cisco.com> Date: Thu, 26 Oct 2000 10:23:00 -0700 Reply-To: Gopal Dommety Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gopal Dommety Subject: Re: [MOBILE-IP] WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt) X-To: Annika Jonsson To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <3.0.32.20001026175546.00cd61a8@era-t.ericsson.se> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA26546 At 05:55 PM 26/10/00 +0200, Annika Jonsson wrote: >Hello Tom, > >here is part two of my answer to your comments. (if you didn't see the >first one, it's probably because I sent it from the wrong address, and it >went via the moderator) > >These comments are all about the issue of different message types for >regional registrations. Summary: I still think it's the best way. See my >arguments below. > >/Annika > >At 02:02 2000-10-25 +0300, Tom K. Weckström wrote: >> >> >>Hello Charlie, >> >>Here comes my lengthy comments about reg-tunnel-03. Sorry for a long >>email, but there were lots of things to comment. >>I hope the ASCII graphics is not distorted. >>I found quite many issues. >>Some of them might be possible to solve with more explanations (maybe >>I just did not get the ideas). Some of the issues should be solved in >>other ways. More ideas below. Read on. >> >>Regards, >> Tom >> >> >>COMMENTS TO draft-ietf-mobileip-reg-tunnel-03.txt >> >>Tom Weckström >> >>Legend: >>+ = A positive note >>- = A negative note, criticism >>? = A question >>! = Exclamation, either a critical issue or an important suggestion >>idea >>--> = conclusion mark >> >>Ch 1. >>+ Decision power at MN: regional or home registration possible >>? Is it always good to let the MN deicde what kind of registration to >>use? >>? What are the benefits in giving the MN the right to decide? >> >>- Different registration types makes the protocol more complex >> - Changes to std RFC2002 MN >> - Changes to FAs >> > >It has nothing to do with benefits. As I see it it is a _necessity_ for the >MN to know who will process the registration, the HA or an FA, because it >needs to know what security association to use (I feel I am repeating >myself;-). It is possible that it could be solved by having the MN add both >the home and the visited authentication and both the home and the visited You need not do this (adding two authentications) . Because, if you knew to send a reg registration, then the mobile knows which security association and reply to use, and the network can validate that. May be I am missing something. Since you are saying it (the decision to use new messages) has nothing to do with benifits, if what you said above is not true, then we should use the extension method. Thanks -Gopal >replay protection (in case of nounces), and then let the network take the >actual decision, but that introduces even more complexity in the MN. > > >>"We assume that there exist established >> security associations between a GFA and the regional foreign >> agents beneath it." >>---> This implies the RFAs HAVE to know their GFA. >>---> Satwant Kaur's scenario with RFA not knowing the GFA is >>impossible. >>---> No need for different message types for regional and home >>registration. >>---> More transparency and simpleness achieved. >> > >You are right, but my example still holds! I will repeat it here: > >"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." > > > > >>3.5.1. >> >>" it is necessary to distinguish regional registrations from home >> registration. Thus, we introduce new message types for the >> Regional Registration messages." >> >>? Could we make the distinction by defining that every registration >>with a valid MN-FA auth ext is a regional registration? Furthermore, >>if there is no MN-FA auth ext or if that extension is invalid, the FAs >>forward the message upwards in the hierarchy. >>Example: Consider an N-level hierarchy. See image below: >> >> ------ >> | HA | >> ------ >> | >> (Internet) >> | >> ------- >> | GFA | >> ------- >> / \ >> ------- ------- >> | FA1 | | FA2 | >> ------- ------- >> / \ / \ >> ------- ------- ------- ------- >> | FA3 | | FA4 | | FA5 | | FA6 | >> ------- ------- ------- ------- >> \ >> \ >> ------ >> | MN | >> ------ >> >> Figure 1: Mobility Agent Hierarchy >> >> >>! Now, if MN is registered to FA4 and changes to FA6, then it sends >>the >>registration request to FA6 and FA6 does not know the MN-FA auth ext >>in the registration neither has it heard of MN before (no mobility >>bindings existing for MN). Then FA6 jsut forwards the request upwards >>to FA2. FA2 also does not have a clue about MN, so it too forwards the >>request upwards. Finally, GFA knows the MN from its bindings and also >>can validate the MN-FA auth ext. Eventually, this registration became >>regional. Now, if there were no MN-FA auth ext, or if it was invalid, >>also the GFA would have forwarded the message - now to the HA. Maybe >>an invalid auth extensions should result in request denial if the MN >>is known to the FA (i.e. there is a binding for the MN in the >>FA). After all the MN is known, and the authentication does not match. >> >>! Anyway, there seems to be no need for separate regional and home >>registration messages. The MN still has the choice to either include >>the FA-MN auth ext or leave it away. >> >>! NOTE, that this is directly applicable to N-level hierarchies! >> >> > >I agree, it could be done in this way, but you still need a change to an >RFC2002 MN, since it will always include the MN-FA auth. ext if it has an >SA with the FA (that is mandatory). Secondly, one argument that persuaded >us that different message types is a "cleaner" solution is that we didn't >like the idea to use e.g. the auth. ext. to let an FA decide what it >"thinks" that the MN wants. This is why: normally if the authentication >fails, this error should be reported back to the MN and no registration be >made. The authentication could fail for several reasons! It feels wrong, >both "decisionwise" and "securitywise", to use this failure to authenticate >the message as an indication of something that the MN wants the FA to do. > > > > > >> >> >>6.1. >> >> >>" >> GFA IP Address >> The IP address of the Gateway Foreign Agent. (Replaces >> Home Agent field in Registration Request message >> in [9].) >> >> Care-of Address >> Care-of address of local foreign agent; MAY be set to >> zero. >>" >> >>? Why should the HA field be replaced? There is the COA field to >>be used for the GFA IP addr. The FAs in the hierarchy can use >>extensions or directly the source IP of the outer header to get the >>address of the "lower" agent in the hierarchy as the registration >>traverses upwards. >> >>? Why is the COA field filled with the local COA? The lowest FA >>always knows behind which interface the MN is. The FA aboe the lowest >>FA knows the interface from which the first reg.request came and also >>the IP of the lowest FA. This continues from the bottom of the FA tree >>to the top, i.e., the GFA. ALL that is needed in MIP sense is the GFA >>IP in the COA field and this is for the HA. The hierarchy of FAs >>handles the tunneling in the hierarhcy by other means. >> >> > >Why use extensions when we don't have to? In a regional registration the HA >address is not needed, so we reuse that field. Actually, the GFA kind of >acts as a "local HA", so doing it in this way makes it very consistent with >RFC2002. > >> >> >>A. >> >>" - 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;" >> >>! Dynamics works with nonces also, and it supports regional >>registrations. I have to find out how the nonce synchronization is >>done in Dynamics. Perhaps the lack of FA-MN auth ext (again) is enough >>for the MN to control between home and regional registrations. >> >> > >It would be interesting to see your solution. > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 26 13: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 NAA26552 for ; Thu, 26 Oct 2000 13:26:39 -0400 (EDT) Received: from standards (47.234.32.16:1173) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAB4A0@standards.nortelnetworks.com>; Thu, 26 Oct 2000 13:11:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 51191 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 26 Oct 2000 13:11:01 -0400 Received: from omega.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAB49E@standards.nortelnetworks.com>; Thu, 26 Oct 2000 13:11:01 -0400 Received: from gopal.cisco.com (dhcp-171-70-61-178.cisco.com [171.70.61.178]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA04499; Thu, 26 Oct 2000 10:26:29 -0700 (PDT) X-Sender: gdommety@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 References: <3.0.32.20001023104432.0068c9bc@era-t.ericsson.se> <39F4B45C.87DC28F5@cc.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Approved-By: Gopal Dommety Message-ID: <4.3.2.7.2.20001026102413.00c95490@omega.cisco.com> Date: Thu, 26 Oct 2000 10:25:06 -0700 Reply-To: Gopal Dommety Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gopal Dommety Subject: Re: [MOBILE-IP] WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt) X-To: Charlie Perkins To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <39F4B895.C718AE7D@iprg.nokia.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA26552 At 03:15 PM 23/10/00 -0700, Charlie Perkins wrote: >Hello Tom, > >> I discovered the 'hidden' assumption of RFAs and their GFA knowing >> abouit each other from the draft. :-) > >It wasn't intended to be hidden. How can we make it more explicit? Would help if you could make this assumption explicit. thanks Gopal >> I will check the security association issue more closely. >> I am not completely convinced that there needs to be a separate >> message type for different uses of security associations. >> Why couldn't the FAs automatically consider the registration as a home >> reg if there is not acceptable sec association used for FA-MN >> authentication? > >Because the mobile node is very likely to want to send a home >registration whenever it feels like renewing its current care-of >address, thereby increasing the lifetime. We do not want to make >any implicit judgements about type of registration based on the >remaining registratoin lifetime. That sounds like a really bad idea. > >At any time, the mobile node should be allowed to send either a >home registration or a regional registration, subject only to the >constraint that the lifetime of the regional registration should not >exceed the lifetime of the regional registration. > >> I will send my comment later. >> Hopefully not too late. :-/ >> When does the last call end? > >I think formally it might have ended a month ago, but the purpose >after all is to find out if the draft is ready for advancement. So, >I think it's just fine to ask questions. So far, the main comments >we have gotten about necessary changes is to put in more details >about running in the mode where the "first" foreign agent becomes >the GFA (what others have called "anchoring"). > >Other than that, I think we're ready to go depending on your >comments. > >Regards, >Charlie P. > >Annika Jonsson wrote: > >> > >> > Hi Tom, >> > >> > see comments below. >> > >> > At 23:55 2000-10-21 +0300, Tom K. Weckström wrote: >> > >Hi, >> > > >> > >In my opinion, additional messages makes the protocol partly clearer, >> > >but partly more complex. >> > > >> > >Here are my questions (please point me to the appropriate messages, if >> > >these questions have already been discussed :) >> > > >> > >- Is it possible/needed that a FA does not know the GFA or GFAs above >> > >it? >> > >I think FAs and GFAs should have trust relationships = knowledge of >> > >each other. >> > >> > Yes, FA:s and GFA:s need to know about each other. That is also stated in >> > the draft (well, indirectly, since it says that they need to have >> > established security associations between them). >> > >> > > >> > >- Why do we need to add intelligence to the mobile node? >> > >Having a totally transparent hierarchy is possible. The MN would speak >> > >standard RFC2002 MIP and would still get the best efficiency in >> > >registrations through the regionalized handoffs. By defining new >> > >messages we do add intelligence to MN. It must know what kind of >> > >registrations to send. >> > > >> > >> > Because, as I said in my last mail, the MN needs to know if the >> > registration request will be processed in the home or in the visited domain >> > to know which security association and replay protection to use. We didn't >> > find any way to get around this. But another goal is to support RFC2002 >> > MN:s also. In this draft, they don't get the benefits of the regional >> > registrations, but they will work. >> > >> > /Annika >> > >> > >And my totally subjective opinion: >> > > ;-) >> > >Despite the lively discussion about regionalized handoffs etc., I >> > >still have not seen many transparent, fast and *implemented* >> > >approaches. If the ideas in the drafts have been implemented, please >> > >provide the community some links to the material. Dynamics - HUT >> > >Mobile IP has been rocking for 1.5 years now. Dynamics is transparent >> > >to the Mobile Node and still provides fast handoffs. >> > > >> > >Should we write a competing draft? ;-) We didn't do it in the first >> > >place because we felt it would just slow down the fast handoff design >> > >process. Unfortunately the process has been unbelievably slow. I am >> > >really looking forward to a solution in this issue. >> > > >> > >Regards, >> > > Tom >> > > >> > >-- >> > > Tom Weckström Dynamics group >> > > Helsinki University of Technology >> > > dynamics@cs.hut.fi >> > > >> > >http://www.cs.hut.fi/Research/Dynamics/ >> > > >> > > >> > >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). >> > >> >> > >> 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" >> > >> To: >> > >> 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 >> > >> > > >> > >> > >> > > >> >> -- >> 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 Oct 26 14:53: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 OAA06815 for ; Thu, 26 Oct 2000 14:53:33 -0400 (EDT) Received: from standards (47.234.32.16:1173) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAB617@standards.nortelnetworks.com>; Thu, 26 Oct 2000 14:36:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 51687 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 26 Oct 2000 14:36:05 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAB615@standards.nortelnetworks.com>; Thu, 26 Oct 2000 14:36:04 -0400 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 LAA12421; Thu, 26 Oct 2000 11:51:38 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9QIpZc07707; Thu, 26 Oct 2000 11:51:35 -0700 X-Virus-Scanned: Thu, 26 Oct 2000 11:51:35 -0700 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) smtpdO84c8i; Thu, 26 Oct 2000 11:51:29 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <4.3.2.7.2.20001026101605.00b63d90@omega.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: charliep@IPRG.NOKIA.COM Message-ID: <39F87D33.81D823E9@iprg.nokia.com> Date: Thu, 26 Oct 2000 11:51:31 -0700 Reply-To: "Charles E. Perkins" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt) X-To: Gopal Dommety X-cc: Annika Jonsson , Eva Gustafsson To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Gopal, At 05:55 PM 26/10/00 +0200, Annika Jonsson wrote: >> It has nothing to do with benefits. As I see it it is a _necessity_ for the >> MN to know who will process the registration, the HA or an FA, because it >> needs to know what security association to use (I feel I am repeating >> myself;-). It is possible that it could be solved by having the MN add both >> the home and the visited authentication and both the home and the visited Gopal Dommety wrote: > You need not do this (adding two authentications). Because, if you knew to > send a reg registration, then the mobile knows which security association > and reply to use, and the network can validate that. May be I am missing > something. If the mobile node sends a home registration, then it needs to use the security association with the home agent. If the mobile node sends a regional registration, then it needs to use the security association with the regional mobility agent (e.g., GFA). The mobile node does know which security association to use, depending on which kind of registration it is performing. What does it mean, "the network can validate that"? > Since you are saying it (the decision to use new messages) has nothing > to do with benifits, if what you said above is not true, then we should > use the extension method. The decision has to do with protocol correctness, feature availability, and enabling natural processing techniques for the mobile entities. I think this is the bottom line on what others have said. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 26 16:04: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 QAA15297 for ; Thu, 26 Oct 2000 16:04:18 -0400 (EDT) Received: from standards (47.234.32.16:3851) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAB6EB@standards.nortelnetworks.com>; Thu, 26 Oct 2000 15:46:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 51964 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 26 Oct 2000 15:46:45 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAB6E9@standards.nortelnetworks.com>; Thu, 26 Oct 2000 15:46:45 -0400 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 NAA18621; Thu, 26 Oct 2000 13:02:20 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9QK2Io03302; Thu, 26 Oct 2000 13:02:18 -0700 X-Virus-Scanned: Thu, 26 Oct 2000 13:02:18 -0700 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) smtpd67ViDa; Thu, 26 Oct 2000 13:02:12 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <3.0.32.20001026105756.00e8d020@era-t.ericsson.se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Approved-By: charliep@IPRG.NOKIA.COM Message-ID: <39F88DC3.73B2733@iprg.nokia.com> Date: Thu, 26 Oct 2000 13:02:11 -0700 Reply-To: "Charles E. Perkins" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt) X-To: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" X-cc: Annika Jonsson To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hello Tom, At 02:02 2000-10-25 +0300, Tom K. Weckström wrote: > "and it SHOULD be protected by an FA-FA Authentication extension." > ? Where is FA-FA auth ext described? In another draft, I suppose. This is a subtype of the Mobile IP Generalized Authentication, which is described in draft-ietf-mobileip-challenge-13.txt, as mentioned in section 7. The referenced draft has, I think, passed through Last Call and is awaiting publication -- but I might be wrong on this. We should put more cross-references in. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 26 16:12: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 QAA16229 for ; Thu, 26 Oct 2000 16:12:20 -0400 (EDT) Received: from standards (47.234.32.16:3851) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAB735@standards.nortelnetworks.com>; Thu, 26 Oct 2000 15:54:47 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 52061 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 26 Oct 2000 15:54:47 -0400 Received: from motgate3.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAB733@standards.nortelnetworks.com>; Thu, 26 Oct 2000 15:54:46 -0400 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate3.mot.com (motgate3 2.1) with ESMTP id NAA13320 for ; Thu, 26 Oct 2000 13:07:27 -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 NAA14481 for ; Thu, 26 Oct 2000 13:10:19 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Thu, 26 Oct 2000 15:10:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Approved-By: Roberts Philip-qa3445 Message-ID: Date: Thu, 26 Oct 2000 15:10:13 -0500 Reply-To: Roberts Philip-qa3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Philip-qa3445 Subject: [MOBILE-IP] san diego reminder To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi folks, just a reminder that we're taking requests for slots in the Mobile IP meeting. Let us know the name of the presenter, the name of the I-D, and the amount of time requested. Thanks, Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 26 17:19: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 RAA27784 for ; Thu, 26 Oct 2000 17:19:46 -0400 (EDT) Received: from standards (47.234.32.16:3851) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAB801@standards.nortelnetworks.com>; Thu, 26 Oct 2000 17:02:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 52302 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 26 Oct 2000 17:02:10 -0400 Received: from smtp-2.hut.fi by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAB7EF@standards.nortelnetworks.com>; Thu, 26 Oct 2000 16:52:09 -0400 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 AAA96569; Fri, 27 Oct 2000 00:07:40 +0300 (EEST) 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.20001026175546.00cd61a8@era-t.ericsson.se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Approved-By: tom@SMTP.HUT.FI Message-ID: <39F89D2D.AB96B778@cc.hut.fi> Date: Fri, 27 Oct 2000 00:07:57 +0300 Reply-To: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" Organization: HUT Subject: Re: [MOBILE-IP] WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt) X-To: Annika Jonsson X-cc: Charlie Perkins To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hi, I am slowly starting to "buy" the idea of separate message types for regional and home registrations... More comments below. I am waiting your reply about the other issues I mentioned. Here is a brief checklist of issues not handled in this email (or in your reply). - Revealing the hierarchy in advertisements vs - Using previous FA NAI extensions * Limiting the solution to 2 levels vs * Making generic solution that is ready for N-levels. o Forcing registrations from co-located COA to GFA vs o Always using the optimal RFA for handling the registrations x Possibility to use HA hirarchies (possibly another draft). Annika Jonsson wrote: > > These comments are all about the issue of different message types for > regional registrations. Summary: I still think it's the best way. See my > arguments below. > > /Annika > > > >COMMENTS TO draft-ietf-mobileip-reg-tunnel-03.txt > > > > It has nothing to do with benefits. As I see it it is a _necessity_ for the > MN to know who will process the registration, the HA or an FA, because it > needs to know what security association to use (I feel I am repeating > myself;-). It is possible that it could be solved by having the MN add both > the home and the visited authentication and both the home and the visited > replay protection (in case of nounces), and then let the network take the > actual decision, but that introduces even more complexity in the MN. > > > > >"We assume that there exist established > > security associations between a GFA and the regional foreign > > agents beneath it." > >---> This implies the RFAs HAVE to know their GFA. > >---> Satwant Kaur's scenario with RFA not knowing the GFA is > >impossible. > >---> No need for different message types for regional and home > >registration. > >---> More transparency and simpleness achieved. > > > > You are right, but my example still holds! I will repeat it here: > > "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." Yes, MN needs to be able to control what kind of registration it requests. Your problem in the example above comes from a case where you would use GFA's IP in the HA field and only one type of registration message. That is the wrong way, we both know that. We end up to two alternatives already presented, but I write them here to make WG "voting" easier: A) Use separate message types for regional and home registrations. Use FA IP in the "HA field" of the regional registration. Actually, if this is a separate message type, then the RFC's sepcification is not misused, because we are talking about an entiryl new message here. :) B) Use only one registration request message type. Add FA-MN auth.ext. to registration, if regional registration is requested. Always use HA IP in its field. The registration can still be forwarded up to HA, if FAs decide so. MN will know the "destiny" of the registration only when regreply arrives. (with Home auth ext. or with foreign auth ext.) > > > >3.5.1. > > > >" it is necessary to distinguish regional registrations from home > > registration. Thus, we introduce new message types for the > > Regional Registration messages." > > > >? Could we make the distinction by defining that every registration > >with a valid MN-FA auth ext is a regional registration? Furthermore, > >if there is no MN-FA auth ext or if that extension is invalid, the FAs > >forward the message upwards in the hierarchy. > >Example: Consider an N-level hierarchy. See image below: > > > > ------ > > | HA | > > ------ > > | > > (Internet) > > | > > ------- > > | GFA | > > ------- > > / \ > > ------- ------- > > | FA1 | | FA2 | > > ------- ------- > > / \ / \ > > ------- ------- ------- ------- > > | FA3 | | FA4 | | FA5 | | FA6 | > > ------- ------- ------- ------- > > \ > > \ > > ------ > > | MN | > > ------ > > > > Figure 1: Mobility Agent Hierarchy > > > > > >! Now, if MN is registered to FA4 and changes to FA6, then it sends > >the > >registration request to FA6 and FA6 does not know the MN-FA auth ext > >in the registration neither has it heard of MN before (no mobility > >bindings existing for MN). Then FA6 jsut forwards the request upwards > >to FA2. FA2 also does not have a clue about MN, so it too forwards the > >request upwards. Finally, GFA knows the MN from its bindings and also > >can validate the MN-FA auth ext. Eventually, this registration became > >regional. Now, if there were no MN-FA auth ext, or if it was invalid, > >also the GFA would have forwarded the message - now to the HA. Maybe > >an invalid auth extensions should result in request denial if the MN > >is known to the FA (i.e. there is a binding for the MN in the > >FA). After all the MN is known, and the authentication does not match. > > > >! Anyway, there seems to be no need for separate regional and home > >registration messages. The MN still has the choice to either include > >the FA-MN auth ext or leave it away. > > > >! NOTE, that this is directly applicable to N-level hierarchies! > > > > > > I agree, it could be done in this way, but you still need a change to an > RFC2002 MN, since it will always include the MN-FA auth. ext if it has an > SA with the FA (that is mandatory). Secondly, one argument that persuaded > us that different message types is a "cleaner" solution is that we didn't > like the idea to use e.g. the auth. ext. to let an FA decide what it > "thinks" that the MN wants. This is why: normally if the authentication > fails, this error should be reported back to the MN and no registration be > made. The authentication could fail for several reasons! It feels wrong, > both "decisionwise" and "securitywise", to use this failure to authenticate > the message as an indication of something that the MN wants the FA to do. Couple of additional comments: - Changes to RFC2002 MN would still be needed - True. We need an MN taht can leave the foreign euth ext away on purpose to force registration to HA (when we are using approach B above). - It would be good that a RFC2002 MN would be using regional registrations by default when adding the MN-FA auth.ext. by default. As an Internet user I would be concerned, if a proposed standard would not act optimally, but rather consumed bandwidth from the Internet with its non-optimal registration sequences. - "Failure to authenticate" would for me be: there was a foreign auth ext. but we could not verify its authenticity. --> Direct regreply with correct reason code to MN. - Lack of the auth ext. would not mean "failure", but the FA would forward the request onwards. > >? Why should the HA field be replaced? > > Why use extensions when we don't have to? In a regional registration the HA > address is not needed, so we reuse that field. Actually, the GFA kind of > acts as a "local HA", so doing it in this way makes it very consistent with > RFC2002. We come back to options A and B. As I said, using GFA IP in the new message in option A is OK, since it is not anymore a RFC2002 registration request but a new type of request. > >A. > > > >" - 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;" > > > >! Dynamics works with nonces also, and it supports regional > >registrations. I have to find out how the nonce synchronization is > >done in Dynamics. Perhaps the lack of FA-MN auth ext (again) is enough > >for the MN to control between home and regional registrations. I discussed with Jouni. Dynamics can uses nonces for home registrations, i.e., registration requests without MN-FA auth ext. but only timestamps are used in registrations with FA-MN auth. ext. This eliminates the possibility of uncontrolled nonce asynchronization. > It would be interesting to see your solution. :-) Download Dynamics from the URL in my signature. You are also welcome to visit Finland to see it work. Unfortunately we do not have any conference papers in pipeline or budget to travel to WG meetings. Best regards, Tom -- Tom Weckström Dynamics group Helsinki University of Technology dynamics@cs.hut.fi http://www.cs.hut.fi/Research/Dynamics/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 26 17:46: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 RAA09807 for ; Thu, 26 Oct 2000 17:46:53 -0400 (EDT) Received: from standards (47.234.32.16:3851) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAB861@standards.nortelnetworks.com>; Thu, 26 Oct 2000 17:29:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 52454 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 26 Oct 2000 17:29:38 -0400 Received: from fridge.docomo-usa.com (216.98.102.228:57730) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAB85F@standards.nortelnetworks.com>; Thu, 26 Oct 2000 17:29:36 -0400 Received: from NTTD2GMTPW5TAN (dhcp24.docomo-usa.com [172.21.96.24]) by fridge.docomo-usa.com (Postfix) with SMTP id 12B467F804 for ; Thu, 26 Oct 2000 14:46:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B1_01C03F5B.3CE8AFB0" 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: Johnny Matta Message-ID: <00b401c03f95$e950af70$186015ac@NTTD2GMTPW5TAN> Date: Thu, 26 Oct 2000 14:44:26 -0700 Reply-To: Johnny Matta Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Johnny Matta Subject: [MOBILE-IP] Status of draft To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_00B1_01C03F5B.3CE8AFB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Can someone please give me a follow-up on draft = (November 98, Expires May 99)? = Is there other work currently underway addressing the issues of RSVP = integration with Mobile IP? How about DiffServ issues with Mobile IP? Thank you. Johnny M MATTA Research Engineer DoCoMo Communications Laboratories USA, Inc. Email: matta@dcl.docomo-usa.com Phone: 1-408-451-4727 Fax: 1-408-573-1090 181 Metro Drive Suite 300 San Jose, CA 95110 ------=_NextPart_000_00B1_01C03F5B.3CE8AFB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hello,
 
Can someone please give me a follow-up = on draft=20 <draft-fhns-rsvp-support-in-mipv6-00.txt>=20 (November 98, Expires May 99)? Is there other work currently underway = addressing=20 the issues of RSVP integration with Mobile IP?
How about DiffServ issues with Mobile=20 IP?
 
Thank you.
 
Johnny M MATTA
Research = Engineer
DoCoMo=20 Communications Laboratories USA, Inc.
Email: matta@dcl.docomo-usa.com
Phone:=20 1-408-451-4727
Fax: 1-408-573-1090
181 Metro Drive Suite = 300
San Jose,=20 CA 95110
------=_NextPart_000_00B1_01C03F5B.3CE8AFB0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 26 18:43: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 SAA02776 for ; Thu, 26 Oct 2000 18:43:10 -0400 (EDT) Received: from standards (47.234.32.16:3851) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAB8FE@standards.nortelnetworks.com>; Thu, 26 Oct 2000 18:25:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 52663 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 26 Oct 2000 18:25:42 -0400 Received: from nsm-mail2.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAB8FC@standards.nortelnetworks.com>; Thu, 26 Oct 2000 18:25:42 -0400 Received: from jtrostle-nt2 (dhcp-171-71-229-14.cisco.com [171.71.229.14]) by nsm-mail2.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id PAA09805; Thu, 26 Oct 2000 15:41:12 -0700 (PDT) X-Sender: jtrostle@nsm-mail2 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Approved-By: Jonathan Trostle Message-ID: <4.1.20001026154128.016cf810@nsm-mail2> Date: Thu, 26 Oct 2000 15:43:02 -0700 Reply-To: Jonathan Trostle Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jonathan Trostle Subject: Re: [MOBILE-IP] san diego reminder X-To: Roberts Philip-qa3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: I have a draft in this area that I will submit before Nov. 17. What is the deadline for submitting a request for a slot? Thanks, Jonathan At 03:10 PM 10/26/00 -0500, Roberts Philip-qa3445 wrote: >Hi folks, > > just a reminder that we're taking requests for slots in the Mobile IP >meeting. Let us know the name of the presenter, the name of >the I-D, and the amount of time requested. > >Thanks, >Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 26 20:43: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 UAA14289 for ; Thu, 26 Oct 2000 20:43:58 -0400 (EDT) Received: from standards (47.234.32.16:3851) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBABA6E@standards.nortelnetworks.com>; Thu, 26 Oct 2000 20:26:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 53133 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 26 Oct 2000 20:26:31 -0400 Received: from m018.com (210.112.10.141:1837) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBABA6C@standards.nortelnetworks.com>; Thu, 26 Oct 2000 20:26:31 -0400 Received: from ns ([210.112.7.7]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 27 Oct 2000 09:38:52 +0900 References: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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: "Lee, Jiwoong" Message-ID: <006401c03fae$c7f8bac0$d012060a@hansol.co.kr> Date: Fri, 27 Oct 2000 09:42:27 +0900 Reply-To: "Lee, Jiwoong" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lee, Jiwoong" Subject: Re: [MOBILE-IP] san diego reminder X-To: Roberts Philip-qa3445 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear Phil. On 17 Oct, I sumitted an ID named "SGM Support in Mobile IP" and I'm waiting for the approvals from Mobile IP WG chairs as a WG discussion topic. If it is approved, I'd like to request a time slot in San Diego meeting. Presenter: Jiwoong Lee Name of ID: SGM Support in Mobile IP Time: 6min Thank you. Please give me any kind of comment. Regards, Jiwoong Lee ----- Original Message ----- From: "Roberts Philip-qa3445" To: Sent: Friday, October 27, 2000 5:10 AM Subject: [MOBILE-IP] san diego reminder > Hi folks, > > just a reminder that we're taking requests for slots in the Mobile IP > meeting. Let us know the name of the presenter, the name of > the I-D, and the amount of time requested. > > Thanks, > Phil From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 26 21:13: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 VAA20649 for ; Thu, 26 Oct 2000 21:13:08 -0400 (EDT) Received: from standards (47.234.32.16:3851) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBABADE@standards.nortelnetworks.com>; Thu, 26 Oct 2000 20:55:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 53282 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 26 Oct 2000 20:55:44 -0400 Received: from fezik.qualcomm.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBABADC@standards.nortelnetworks.com>; Thu, 26 Oct 2000 20:55:43 -0400 Received: from mlioy.qualcomm.com (mlioy.qualcomm.com [129.46.219.140]) by fezik.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id SAA09281 for ; Thu, 26 Oct 2000 18:11:16 -0700 (PDT) X-Sender: mlioy@mail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: Marcello Lioy Message-ID: <4.3.1.2.20001026175829.00b9b4a0@mail1.qualcomm.com> Date: Thu, 26 Oct 2000 18:09:59 -0700 Reply-To: Marcello Lioy Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Marcello Lioy Subject: [MOBILE-IP] The prefix length extension To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This may seem a naive question but here goes anyway: How can the addresses in a router advertisement message have different prefix lengths? Shouldn't the addresses that are advertised in these messages all be on interfaces on the subnet in question? Doesn't that imply that they all have the same network prefix length? What am I missing? Also why doesn't the prefix length extension refer to the care-of-addresses rather than the router addresses? ---------------------------------------------------------------------- Marcello Lioy Voice: x18220 AA-318A Pager: 635-0867 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 26 22:31: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 WAA08989 for ; Thu, 26 Oct 2000 22:31:33 -0400 (EDT) Received: from standards (47.234.32.16:2775) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBABB53@standards.nortelnetworks.com>; Thu, 26 Oct 2000 22:14:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 53441 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 26 Oct 2000 22:14:04 -0400 Received: from sparrow.ee.nus.edu.sg by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBABB51@standards.nortelnetworks.com>; Thu, 26 Oct 2000 22:14:03 -0400 Received: from localhost (ccfoo@localhost) by sparrow.ee.nus.edu.sg (8.9.3/8.9.3) with ESMTP id IAA05648; Thu, 28 Oct 1971 08:34:09 +0730 (SGT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Approved-By: Foo Chun Choong Message-ID: Date: Thu, 28 Oct 1971 08:34:09 +0730 Reply-To: Foo Chun Choong Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Foo Chun Choong Subject: Re: [MOBILE-IP] Status of draft X-To: Johnny Matta To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <00b401c03f95$e950af70$186015ac@NTTD2GMTPW5TAN> Hi Johnny, There was some work addressing RSVP integration with MIPv4 here in NUS. Do check out http://mip.ee.nus.edu.sg for documents and more details. Basically, we used "Tunnel Support for RSVP" to enable resource reservation support within the MIPv4 tunnel. A similar scheme was also introduced by UCLA. Best regards, Foo Chun Choong, Open Source Software Lab, National University of Singapore http://opensource.nus.edu.sg On Thu, 26 Oct 2000, Johnny Matta wrote: > > Hello, > > Can someone please give me a follow-up on draft (November 98, Expires May 99)? Is there other work currently underway addressing the issues of RSVP integration with Mobile IP? > How about DiffServ issues with Mobile IP? > > Thank you. > > Johnny M MATTA > Research Engineer > DoCoMo Communications Laboratories USA, Inc. > Email: matta@dcl.docomo-usa.com > Phone: 1-408-451-4727 > Fax: 1-408-573-1090 > 181 Metro Drive Suite 300 > San Jose, CA 95110 > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Oct 26 22:49: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 WAA15044 for ; Thu, 26 Oct 2000 22:49:15 -0400 (EDT) Received: from standards (47.234.32.16:2775) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBABBB9@standards.nortelnetworks.com>; Thu, 26 Oct 2000 22:31:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 53579 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 26 Oct 2000 22:31:49 -0400 Received: from m018.com (210.112.10.141:3326) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBABBB7@standards.nortelnetworks.com>; Thu, 26 Oct 2000 22:31:49 -0400 Received: from ns ([210.112.7.7]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 27 Oct 2000 11:44:13 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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: "Lee, Jiwoong" Message-ID: <00fd01c03fc0$49eccba0$d012060a@hansol.co.kr> Date: Fri, 27 Oct 2000 11:47:47 +0900 Reply-To: "Lee, Jiwoong" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lee, Jiwoong" Subject: [MOBILE-IP] [FW] I-D ACTION:draft-lee-sgm-support-mobileip-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit FYI. Thank you. ---------------------------------------------------------------------------- ---- To: IETF-Announce: ; Subject: I-D ACTION:draft-lee-sgm-support-mobileip-00.txt From: Internet-Drafts@ietf.org Date: Wed, 18 Oct 2000 06:31:54 -0400 Reply-to: Internet-Drafts@ietf.org Sender: nsyracus@cnri.reston.va.us ---------------------------------------------------------------------------- ---- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SGM support in Mobile IP Author(s) : J. Lee Filename : draft-lee-sgm-support-mobileip-00.txt Pages : 14 Date : 17-Oct-00 In the current version of mobile IP a home agent converts a incoming generic multicast datagram to multiple unicast- encapsulated datagrams addressed to each mobile node. This kind of multicast handling logically works, while suffering from the performance degradation. Small Group Multicast (SGM) is a newly developed multicast protocol whose level 3.5 header carries multiple unicast destination addresses [2]. SGM support in mobile IP enables the home agent to forward a generic multicast datagram to a foreign agent with one SGM datagram, eliminating the severe performance degradation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lee-sgm-support-mobileip-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-lee-sgm-support-mobileip-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-lee-sgm-support-mobileip-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-type: text/plain From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 27 04:03: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 EAA16076 for ; Fri, 27 Oct 2000 04:03:24 -0400 (EDT) Received: from standards (47.234.32.16:3752) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBABDAF@standards.nortelnetworks.com>; Fri, 27 Oct 2000 3:45:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 54221 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 27 Oct 2000 03:45:32 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBABDAD@standards.nortelnetworks.com>; Fri, 27 Oct 2000 3:45:31 -0400 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 e9R817Z17356; Fri, 27 Oct 2000 10:01:07 +0200 (MEST) Received: from e00105a2d1ed7 by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id KAA09292; Fri, 27 Oct 2000 10:01:07 +0200 X-Sender: erajoaa@era-t.ericsson.se X-Mailer: Windows Eudora Pro Version 3.0 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Approved-By: Annika Jonsson Message-ID: <3.0.32.20001027095827.00cd3cc0@era-t.ericsson.se> Date: Fri, 27 Oct 2000 09:58:28 +0200 Reply-To: Annika Jonsson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Annika Jonsson Subject: Re: [MOBILE-IP] WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt) X-To: Gopal Dommety To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM At 10:23 2000-10-26 -0700, Gopal Dommety wrote: >>>Ch 1. >>>+ Decision power at MN: regional or home registration possible >>>? Is it always good to let the MN deicde what kind of registration to >>>use? >>>? What are the benefits in giving the MN the right to decide? >>> >>>- Different registration types makes the protocol more complex >>> - Changes to std RFC2002 MN >>> - Changes to FAs >>> >> >>It has nothing to do with benefits. As I see it it is a _necessity_ for the >>MN to know who will process the registration, the HA or an FA, because it >>needs to know what security association to use (I feel I am repeating >>myself;-). It is possible that it could be solved by having the MN add both >>the home and the visited authentication and both the home and the visited > >You need not do this (adding two authentications) . Because, if you knew to > send a reg registration, then the >mobile knows which security association and reply to use, and the network can >validate that. May be I am missing something. > >Since you are saying it (the decision to use new messages) has nothing to do with benifits, if >what you said above is not true, then we should use the extension method. > Hi Gopal, you missunderstood me. I was answering Toms question, and what I meant is: it is not a "benefit" that the MN decides wich kind of registration it is, it is necessary (which you agree on). To the question of whether the MN should indicate this decision with message types or extensions, I still think it is a great "benefit" that this is done with message types (see my other comments to Tom). /Annika >Thanks >-Gopal > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Oct 27 17:27: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 RAA05927 for ; Fri, 27 Oct 2000 17:27:12 -0400 (EDT) Received: from standards (47.234.32.16:2369) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAC362@standards.nortelnetworks.com>; Fri, 27 Oct 2000 17:09:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 56070 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 27 Oct 2000 17:09:24 -0400 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAC360@standards.nortelnetworks.com>; Fri, 27 Oct 2000 17:09:24 -0400 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA14726 for ; Fri, 27 Oct 2000 14:24:44 -0700 (MST)] Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA08677 for ; Fri, 27 Oct 2000 14:24:43 -0700 (MST)] Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Fri, 27 Oct 2000 16:24:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Approved-By: Roberts Philip-qa3445 Message-ID: Date: Fri, 27 Oct 2000 16:24:41 -0500 Reply-To: Roberts Philip-qa3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Philip-qa3445 Subject: [MOBILE-IP] v4 fast handoff drafts To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi folks, the v4 fast handoff design team completed its work some time ago now and submitted 2 drafts to the mailing list: draft-calhoun-mobileip-proactive-fa-02.txt draft-elmalki-mobileip-fast-handoffs-03.txt The design team was unable to reach a consensus on which of these to recommend to the working group to be the working group item for v4 fast handoff. We anticipated more discussion from the working group, but only saw a few emails and those from people who were on the design team. So the chairs would like to solicit the working group for input about which of these two drafts it would like to see as a working group item for fast handoff. Please review the drafts carefully and provide comments to the list. We'd ideally like to be able to get some closure before San Diego. Phil and Raj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Oct 28 15:55:07 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16385 for ; Sat, 28 Oct 2000 15:55:06 -0400 (EDT) Received: from standards (47.234.32.16:4966) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAC78E@standards.nortelnetworks.com>; Sat, 28 Oct 2000 15:37:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 57579 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 28 Oct 2000 15:37:11 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAC786@standards.nortelnetworks.com>; Sat, 28 Oct 2000 15:27:09 -0400 Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id OAA03505 for ; Sat, 28 Oct 2000 14:42:44 -0500 (CDT) 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 WAA43557; Sat, 28 Oct 2000 22:42:31 +0300 (EEST) 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> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Approved-By: tom@SMTP.HUT.FI Message-ID: <39FB2C30.4A80518D@cc.hut.fi> Date: Sat, 28 Oct 2000 22:42:40 +0300 Reply-To: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" Organization: HUT Subject: Re: [MOBILE-IP] WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt) X-To: Annika Jonsson , Mobile IP list To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hi Annik and WG. My comments to Annikas first reply, which I somehow managed not to receive. Thanks Annika for resending it to me. Annika Jonsson wrote: > >>Ch 3.1 > >>? Is there a possibility to make a HA hierarchy as well? > >> If not, why then? > >>--> Possibly another draft. Could be derived from J.K.Malinen's > >>thesis. > >> > > > >Sure it is, it was included in one of the predecessors to this draft. We > felt it would be easier to handle it in separate drafts, and we think the > hierarchical FA:s are more important. Agreed. This could be handled in another draft. There could also be a draft about using private addresses in FAs and HAs in the hierarchies and a solution for allowing duplicate private home addresses for MNs from different home organizations. These are all solved in Jouni Malinen's thesis from March/2000. Check it from Dynamics web site (in signature). > >>3.1.1. > >>? Why only assume two levels of FAs in the visited domain? > >> > > > It's mainly for pedagogic reasons. It makes the description of the > protocol easier and clearer, and also we think that is an important > scenario. In this way we first describe the basics of the protocol, and > then add the multiple level hierarchies. Annika, I have to disagree. Simplifying issues in design may result in a solution that can not be easily extended - at least not without breaking backwards compatibility. Additionally, a 2-level case is just an exception in a hierarchical environment. I claim one needs to have at least a 3-level example to demonstrate the different kind of scenarios of regional registrations. 1. GFA handling the registration (also in 2-level case) 2. Lowest FA handling the registration (also in 2-level case) 3. Some intermediate FA handling the registration (NOT in the 2-level case) Here "intermediate" means any FA between lowest FA and GFA. So, please improve the draft to handle N-level hierarchies as simply as 2-level hierarhies, and demonstrate at least the three above mentioned examples in the draft. My suggestion is to leave Appendix B to more advanced hierarhcy discussions if necessary and to include N-level aspect to the actrual chapters. > >>3.4.1. > >>? This makes the possible topologies more cumbersome. > >>---> Eg. GFA1, ..., GFA4 are all connected to RFA1 and RFA2 and RFA3 > >>and RFA4. > >>? Why is this needed? For load balancing type of activities? > >> > > > >Yes, we wanted to allow this kind of topology. It can be used for e.g. > load balancing, or, it could be that an MN should use a specific GFA for > different reasons. Ok. Good. No objections on that. :-) > >>? Does the possibility to set GFA address to zero in the request open > >>new holes in the security? E.g. Mallory acts as an additional GFA in > >>the hierarchy and captures MN's reg.reg. coming from RFA1. This gives > >>a possibility to intrude as a GFA into MIP signaling. However, > >>additional bonuses are few. And eventually Mallory could set up his > >>own ISP. > >> > > > >No, when the reply comes back to the RFA, the FA-FA auth. will fail in > that case. You are right. > >>3.4.2. > >> > >>" If the care-of address field is set to zero, the foreign agent > >> assigns a GFA to the mobile node, by some means not described in > >> this specification, and adds a GFA IP Address extension to the > >> Registration Request message." > >> > >>? RFA selects the GFA? RFA has no knowledge of GFA conditions (load, > >>etc.). How could an RFA make the decision? This could be solved with > >>the topology or by other means, but involves more protocol > >>intelligence anyway and whence adds to complexity. > >> > > > >We specificaly said: "by some means not described in this specification". > It's not necessarily the RFA that decides, but it must have some way of > finding out which GFA to use, of course. Please be careful. If some sort of support for this is build to MN according to the draft/becoming RFC but the mechanism is not in place for selecting GFA, what will happen then? Have you already planned an registration erro message for that? ;) Something like: "Feature not supported". > >>B.2. (quotation deleted, see draft, Chapt B.2.) > >>? So, if the FA hierarchy is not revealed in the advertisements, then > >>the regional registrations always go to the GFA? > No. See your quotation above, the first RFA that recognises the MN replies > (unless the lifetime has expired). This is regardless of whether > hierarchies are advertised or not. How do you assure that the bindings in the FA hierarchy remain consistent when regional registrations are performed in the "intermediate FAs"? I read about the reg.reply with zero lifetime down to the "old" FA of the MN (and the FAs residing on the path between the "old FA" and the "intermediate FA"). As I told, we called this a "tear down" message back in Dynamics 0.5 a year ago, but the solution has a race condition that makes the state of the FA hierarchy inconsistent when packets are lost and results in severe problems. This is why I recommended the "previous FA NAI" extension approach that tackles the problem. More info from Jouni's thesis, or I can explain the solution if desired. > >Thanks for your feedback! Thanks, it is great to be able to give the feedback and possibly improve the becoming RFC. :-) Best regards, Tom -- Tom Weckström Dynamics group Helsinki University of Technology dynamics@cs.hut.fi http://www.cs.hut.fi/Research/Dynamics/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Oct 29 00:48:12 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18789 for ; Sun, 29 Oct 2000 00:48:11 -0400 (EDT) Received: from standards (47.234.32.16:4862) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAC88B@standards.nortelnetworks.com>; 29 Oct 2000 0:30:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 57921 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 29 Oct 2000 00:30:15 -0400 Received: from mail.xnet.com (quake.xnet.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAC889@standards.nortelnetworks.com>; 29 Oct 2000 0:30:14 -0400 Received: from piii (wizkid11.xnet.com [205.243.139.135]) by mail.xnet.com (8.9.3+Sun/XNet-3.0R) with SMTP id XAA06943; Sat, 28 Oct 2000 23:45:51 -0500 (CDT) References: <3.0.32.20001027101806.00ea4abc@era-t.ericsson.se> <39FB2C30.4A80518D@cc.hut.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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: Satwant Kaur Message-ID: <02ae01c04161$8132d800$878bf3cd@piii> Date: Sat, 28 Oct 2000 23:34:18 -0500 Reply-To: Satwant Kaur Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Satwant Kaur Subject: Re: [MOBILE-IP] WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt) X-To: "=?iso-8859-1?Q?Tom_K._Weckstr=F6m?=" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hi Annika, Tom and WG, In this email I would like to comment on Tom's suggestion regarding number of levels of FA in the hierarchy. I understand what Tom has said about having a minimal number of 3 levels for a base case of Hierarchical FA, namely GFA, intermediate FA, lowest FA. I can see that GFA is unique in the sense it is the only agent in Foreign Domain that talks to HA directly, and lowest FA is unique in the sense that it the only Agent that talks to MN directly. Thus intermediate FA is a different entity from both of these since its role is to pass on registration reply/requests to other and open up and build tunnels. And so you want to start with a 3 level scenario of one intermediate FA that can be scaled up by just adding more of intermediate FA's. I had initially thought that way too. But, I want to share what I have started seeing as I am in the process of implementing the roles for these agents. Please feel free to point whatever mistakes I may have made in my understanding: In RFC 2002, we had just two Agents, one in Home network and one in Foreign Network, namely HA and FA, one the transmitter and other the receiver (depending on the direction the packets are going). We needed at least two because we want one of our Agents at both link layer endpoints, HA to grab the packets meant for the MN at link layer, and FA to be able to deliver the packets to MN via link layer. From that stance of having two endpoints of a tunnel, the authors of this draft have discussed a paradigm shift in allowing intermediate nodes whose link layer positions don't matter (as we don't care if they are on Home Subnet or Foreign Subnet). They are just some 'positions' on the route between HA and FA so as to optimize the travel distance/number of signals that are sent to enable transparent communications of world with MN. I think GFA is distinct from both FA and HA, since- (1) As I said there is no restriction on which link layer it is. HA has to be on the same link layer as MN's Home Address, and FA has to be on same link layer that MN is now at. (2) It is the entity that does BOTH encapsulation and decapsulation of the same packets. HA encapsulates incoming packets to MN but decapsulates outgoing packets. Similarly, FA encapsulates outgoing packets from MN but decapsulates incoming packets. Thus GFA is first level of intermediateness between HA and FA by itself. Therefore, I am saying that in a minimal setup of Regional Registration we have to have GFA in addition to nodes in RFC 2002 since it is so different than HA or FA. On the other hand, an intermediate FA, although is an additional level, is not really as distinct from GFA in the above two respects. And I consider it the second level of intermediation. Also regarding intermediate FA, 1. It is not needed even. One can have a decent Regional Registration without it. 2. It is similar to GFA in terms of being an intermediate node between HA and FA, having no link layer restriction, and having to do both encapsulation and decapsulation of same packets. In my mind, the first intermediate level of mediation between FA and HA has already been provided by the GFA. All further levels will be providing yet another level, and may be considered as an appendix. Therefore, I am advocating what exists in the draft, and what Tom has called a 2 level hierarchy as a base case for hierarchical FA. I think the base case is having the first intermediate FA, called GFA. Any other FA's addition can be handled in appendix, and can be built on the model proposed in this draft. Regards, Satwant ----- Original Message ----- From: "Tom K. Weckström" To: Sent: Saturday, October 28, 2000 2:42 PM Subject: Re: [MOBILE-IP] WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt) > Hi Annik and WG. > > My comments to Annikas first reply, which I somehow managed not to > receive. > Thanks Annika for resending it to me. > > Annika Jonsson wrote: > > >>Ch 3.1 > > >>? Is there a possibility to make a HA hierarchy as well? > > >> If not, why then? > > >>--> Possibly another draft. Could be derived from J.K.Malinen's > > >>thesis. > > >> > > > > > >Sure it is, it was included in one of the predecessors to this draft. We > > felt it would be easier to handle it in separate drafts, and we think the > > hierarchical FA:s are more important. > > Agreed. This could be handled in another draft. There could also be a > draft about using private addresses in FAs and HAs in the hierarchies > and a solution for allowing duplicate private home addresses for MNs > from different home organizations. These are all solved in Jouni > Malinen's thesis from March/2000. Check it from Dynamics web site (in > signature). > > > > >>3.1.1. > > >>? Why only assume two levels of FAs in the visited domain? > > >> > > > > > It's mainly for pedagogic reasons. It makes the description of the > > protocol easier and clearer, and also we think that is an important > > scenario. In this way we first describe the basics of the protocol, and > > then add the multiple level hierarchies. > > Annika, I have to disagree. Simplifying issues in design may result in > a solution that can not be easily extended - at least not without > breaking backwards compatibility. > > Additionally, a 2-level case is just an exception in a hierarchical > environment. I claim one needs to have at least a 3-level example to > demonstrate the different kind of scenarios of regional registrations. > 1. GFA handling the registration (also in 2-level case) > 2. Lowest FA handling the registration (also in 2-level case) > 3. Some intermediate FA handling the registration > (NOT in the 2-level case) > Here "intermediate" means any FA between lowest FA and GFA. > > So, please improve the draft to handle N-level hierarchies as simply > as 2-level hierarhies, and demonstrate at least the three above > mentioned examples in the draft. > > My suggestion is to leave Appendix B to more advanced hierarhcy > discussions if necessary and to include N-level aspect to the actrual > chapters. > > > >>3.4.1. > > >>? This makes the possible topologies more cumbersome. > > >>---> Eg. GFA1, ..., GFA4 are all connected to RFA1 and RFA2 and RFA3 > > >>and RFA4. > > >>? Why is this needed? For load balancing type of activities? > > >> > > > > > >Yes, we wanted to allow this kind of topology. It can be used for e.g. > > load balancing, or, it could be that an MN should use a specific GFA for > > different reasons. > > Ok. Good. No objections on that. :-) > > > > >>? Does the possibility to set GFA address to zero in the request open > > >>new holes in the security? E.g. Mallory acts as an additional GFA in > > >>the hierarchy and captures MN's reg.reg. coming from RFA1. This gives > > >>a possibility to intrude as a GFA into MIP signaling. However, > > >>additional bonuses are few. And eventually Mallory could set up his > > >>own ISP. > > >> > > > > > >No, when the reply comes back to the RFA, the FA-FA auth. will fail in > > that case. > > > You are right. > > > > >>3.4.2. > > >> > > >>" If the care-of address field is set to zero, the foreign agent > > >> assigns a GFA to the mobile node, by some means not described in > > >> this specification, and adds a GFA IP Address extension to the > > >> Registration Request message." > > >> > > >>? RFA selects the GFA? RFA has no knowledge of GFA conditions (load, > > >>etc.). How could an RFA make the decision? This could be solved with > > >>the topology or by other means, but involves more protocol > > >>intelligence anyway and whence adds to complexity. > > >> > > > > > >We specificaly said: "by some means not described in this specification". > > It's not necessarily the RFA that decides, but it must have some way of > > finding out which GFA to use, of course. > > Please be careful. If some sort of support for this is build to MN > according to the draft/becoming RFC but the mechanism is not in place > for selecting GFA, what will happen then? Have you already planned an > registration erro message for that? ;) Something like: "Feature not > supported". > > > > >>B.2. > (quotation deleted, see draft, Chapt B.2.) > > > >>? So, if the FA hierarchy is not revealed in the advertisements, then > > >>the regional registrations always go to the GFA? > > > No. See your quotation above, the first RFA that recognises the MN replies > > (unless the lifetime has expired). This is regardless of whether > > hierarchies are advertised or not. > > How do you assure that the bindings in the FA hierarchy remain > consistent when regional registrations are performed in the > "intermediate FAs"? > > I read about the reg.reply with zero lifetime down to the "old" FA of > the MN (and the FAs residing on the path between the "old FA" and the > "intermediate FA"). As I told, we called this a "tear down" message > back in Dynamics 0.5 a year ago, but the solution has a race condition > that makes the state of the FA hierarchy inconsistent when packets are > lost and results in severe problems. This is why I recommended the > "previous FA NAI" extension approach that tackles the problem. More > info from Jouni's thesis, or I can explain the solution if desired. > > > >Thanks for your feedback! > Thanks, it is great to be able to give the feedback and possibly > improve the becoming RFC. :-) > > Best regards, > Tom > > -- > Tom Weckström Dynamics group > Helsinki University of Technology > dynamics@cs.hut.fi > > http://www.cs.hut.fi/Research/Dynamics/ > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Oct 29 06:18: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 GAA21041 for ; Sun, 29 Oct 2000 06:18:55 -0500 (EST) Received: from standards (47.234.32.16:3935) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAC92A@standards.nortelnetworks.com>; 29 Oct 2000 6:01:13 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 58140 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 29 Oct 2000 06:01:12 -0500 Received: from smtp-2.hut.fi by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAC928@standards.nortelnetworks.com>; 29 Oct 2000 5:51:08 -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 NAA47373; Sun, 29 Oct 2000 13:06:38 +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> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Approved-By: tom@SMTP.HUT.FI Message-ID: <39FC04C3.43DBD172@cc.hut.fi> Date: Sun, 29 Oct 2000 13:06:43 +0200 Reply-To: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" Organization: HUT Subject: Re: [MOBILE-IP] WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt) X-To: Satwant Kaur , Annika.Jonsson@era.ericsson.se, "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hello Satwant and others. You have valid points. I agree on all you say about the roles of different agents. And GFA really is the first level of "intermediateness" when thinking from you point of view. BUT: Thinking from the regionality point of view, GFA is the zero level, because it is not intermediate from the regionality point of view. If the registrations go to the HA, they are not regionalized, and thus HA can not be considered as level zero from the regionality point of view. As Annika said, GFA is sort of a replacement for a HA. This is also said in our paper presented in MoMuC99. We called this idea "distribution of mobility agent functionality", because a part of HA's functionality is distributed to FA's (namely the functionality to reply to registration requests). The important example I would like to see in the draft is the example of FAs handling a consistent state information throughout the FA topology. To clarify this operation, I would vote for a 3-level FA hierarchy example. I admit, that even this state example could be simplified to a 2-level example, but I see it would be misleading in two ways: it is more trivial and it urges thinking of only 2-level hierarchies. 2-level hierarchies are likely to be the most used topologies, but as networks grow and needs arise for even more regionalized registrations, deeper FA topologies may gain importance. Let me explain. 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 These (or similar) are important examples that should be handled in the draft for example to justify the use of "previous FA NAI" extension. For example, in the latter example, changing from FA1 to FA2 and to FA3 would result in error, if a "tear down" message from GFA to FA1 was lost after the FA1-->FA2 transition. In that case, the registration reply associated with the FA2-->FA3 transition would be handled by FA1 leaving GFA unaware of the change, i.e., GFA would still route the packets for MN to FA2. When using "previous FA NAI" extension, FA3 would know that the previous FA, FA2, is not under it and would delegate the responsibility to FA1. FA1 would also notice that FA2 is not beneath it in the hierarchy, and would delegate the registration to GFA, which would be able to handle the registration correctly. This solution requires the FAs to be aware of other FAs below them in the hierarchy. This is solved with a specific automatic "FA registration protocol" also designed by Jouni Malinen in his thesis and implemented in Dynamics - HUT Mobile IP v0.7. Of course, also manual configuration could be used. Tear down could be used *in addition* to the "previous FA NAI" extension. The role of the previous FA NAI extension is to make the state of the hierarchy consistent and the role of the tear down message would be just to release the resources from FA2. E.g., FA2 could have had the maximum number of mobility bindings and it would have been unable to serve new MNs before the timeout of the already useless binding. Tear down would then release the resources for other MNs. It is not possible to show examples like this with a 2-level FA hierarchy. A significantly simpler scenario could be shown, though. What do you think, would the simpler scenario be enough to demonstrate the issues involved in FA hierarchies deeply enough to help the implementors avoid failures in coding their implementations? I think guidance to implementors is one of the most important missions of RFCs (and drafts). Would the simpler scenario also demonstrate the solution's capability to extend to any level FA hierarchies? Furthermore, if someone has thought these - to me quite nontrivial - issues through, I think the conclusions should be included to a draft that describes the solution and not to hide them so that everyone would need to re-think the issues and re-invent the solution for 3-level hierarchies. I agree, that a simplistic case could be handled in the main text and 3-level considerations could be left to Appendix, if length of the document becomes an issue, for example. However, these scenarios and the operation of the system elements are so important for the whole concept of regional registrations that I would rather write them to the actual part of the draft, not Appendix. Regards, Tom Satwant Kaur wrote: > > Hi Annika, Tom and WG, > > In this email I would like to comment on Tom's suggestion regarding number > of levels of FA in the hierarchy. > > I understand what Tom has said about having a minimal number of 3 levels for > a base case of Hierarchical FA, namely GFA, intermediate FA, lowest FA. I > can see that GFA is unique in the sense it is the only agent in Foreign > Domain that talks to HA directly, and lowest FA is unique in the sense that > it the only Agent that talks to MN directly. Thus intermediate FA is a > different entity from both of these since its role is to pass on > registration reply/requests to other and open up and build tunnels. And so > you want to start with a 3 level scenario of one intermediate FA that can be > scaled up by just adding more of intermediate FA's. > > I had initially thought that way too. But, I want to share what I have > started seeing as I am in the process of implementing the roles for these > agents. Please feel free to point whatever mistakes I may have made in my > understanding: > > In RFC 2002, we had just two Agents, one in Home network and one in Foreign > Network, namely HA and FA, one the transmitter and other the receiver > (depending on the direction the packets are going). We needed at least two > because we want one of our Agents at both link layer endpoints, HA to grab > the packets meant for the MN at link layer, and FA to be able to deliver the > packets to MN via link layer. > > >From that stance of having two endpoints of a tunnel, the authors of this > draft have discussed a paradigm shift in allowing intermediate nodes whose > link layer positions don't matter (as we don't care if they are on Home > Subnet or Foreign Subnet). They are just some 'positions' on the route > between HA and FA so as to optimize the travel distance/number of signals > that are sent to enable transparent communications of world with MN. > > I think GFA is distinct from both FA and HA, since- > > (1) As I said there is no restriction on which link layer it is. HA has to > be on the same link layer as MN's Home Address, and FA has to be on same > link layer that MN is now at. > > (2) It is the entity that does BOTH encapsulation and decapsulation of the > same packets. HA encapsulates incoming packets to MN but decapsulates > outgoing packets. Similarly, FA encapsulates outgoing packets from MN but > decapsulates incoming packets. > > Thus GFA is first level of intermediateness between HA and FA by itself. > Therefore, I am saying that in a minimal setup of Regional Registration we > have to have GFA in addition to nodes in RFC 2002 since it is so different > than HA or FA. > > On the other hand, an intermediate FA, although is an additional level, is > not really as distinct from GFA in the above two respects. And I consider it > the second level of intermediation. > > Also regarding intermediate FA, > 1. It is not needed even. One can have a decent Regional Registration > without it. > 2. It is similar to GFA in terms of being an intermediate node between HA > and FA, having no link layer restriction, and having to do both > encapsulation and decapsulation of same packets. > > In my mind, the first intermediate level of mediation between FA and HA has > already been provided by the GFA. > > All further levels will be providing yet another level, and may be > considered as an appendix. > > Therefore, I am advocating what exists in the draft, and what Tom has called > a 2 level hierarchy as a base case for hierarchical FA. I think the base > case is having the first intermediate FA, called GFA. Any other FA's > addition can be handled in appendix, and can be built on the model proposed > in this draft. > > Regards, > Satwant -- Tom Weckström Dynamics group Helsinki University of Technology dynamics@cs.hut.fi http://www.cs.hut.fi/Research/Dynamics/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Oct 29 08:27: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 IAA15514 for ; Sun, 29 Oct 2000 08:27:50 -0500 (EST) Received: from standards (47.234.32.16:2323) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAC99E@standards.nortelnetworks.com>; 29 Oct 2000 8:10:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 58294 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 29 Oct 2000 08:10:07 -0500 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAC99C@standards.nortelnetworks.com>; 29 Oct 2000 8:10:06 -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 e9TDPdY54303; Sun, 29 Oct 2000 15:25:39 +0200 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 OAA28104; Sun, 29 Oct 2000 14:25: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 OAA33019; Sun, 29 Oct 2000 14:26:12 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Approved-By: Francis.Dupont@ENST-BRETAGNE.FR Message-ID: <200010291326.OAA33019@givry.rennes.enst-bretagne.fr> Date: Sun, 29 Oct 2000 14:26:12 +0100 Reply-To: Francis Dupont Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySupportinIPv6"draft] X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Mon, 23 Oct 2000 09:24:13 PDT. <39F4662D.EA8DD1E4@iprg.nokia.com> I agree, IPsec doesn't provide user authentication (ie. IPsec is not radius) or application level authentication (ie. IPsec is not PGP). IPsec provides only device strong authentication which is required by mobility... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Oct 29 08:47:28 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 IAA23429 for ; Sun, 29 Oct 2000 08:47:22 -0500 (EST) Received: from standards (47.234.32.16:2323) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAC9F2@standards.nortelnetworks.com>; 29 Oct 2000 8:29:38 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 58407 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 29 Oct 2000 08:29:38 -0500 Received: from melimelo.enst-bretagne.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAC9F0@standards.nortelnetworks.com>; 29 Oct 2000 8:29:37 -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 e9TDVCY22895; Sun, 29 Oct 2000 15:31:13 +0200 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 OAA28248; Sun, 29 Oct 2000 14:31: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 OAA33049; Sun, 29 Oct 2000 14:31:46 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Approved-By: Francis.Dupont@ENST-BRETAGNE.FR Message-ID: <200010291331.OAA33049@givry.rennes.enst-bretagne.fr> Date: Sun, 29 Oct 2000 14:31:46 +0100 Reply-To: Francis Dupont Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Francis Dupont Subject: Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySupport in IPv6"draft] X-To: "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Your message of Mon, 23 Oct 2000 10:32:55 PDT. <39F47647.CE0A588C@iprg.nokia.com> In your previous mail you wrote: I'll use the word "exchange" instead of "switch", since the latter was misinterpreted in at least one implementation effort. => misinterpretation MUST be avoided! I hope this is acceptable, and I am also looking for additional comments before the next revision is completed. => you already know my opinion, field exchange is a bit simpler than more abstract way to deal with both home and care-of addresses. Of course both must be protected and it is easier to protect them directly (ie. in ICV and not via SA match) in place (ie. one as the source, one in the home address option). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Oct 29 18:59: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 SAA28968 for ; Sun, 29 Oct 2000 18:59:40 -0500 (EST) Received: from standards (47.234.32.16:4015) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBACB04@standards.nortelnetworks.com>; 29 Oct 2000 18:41:59 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 58797 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 29 Oct 2000 18:41:58 -0500 Received: from dns1.catt.ac.cn (202.106.106.98:3633) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBACB02@standards.nortelnetworks.com>; 29 Oct 2000 18:41:57 -0500 Received: from SERVER (FOSSICKER [172.18.206.117]) by dns1.catt.ac.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id VTFXRSM5; Mon, 30 Oct 2000 07:50:53 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Approved-By: liangxg Message-ID: <000c01c04203$6af43be0$75ce12ac@DOMAIN> Date: Mon, 30 Oct 2000 07:53:01 +0800 Reply-To: liangxg Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: liangxg Subject: [MOBILE-IP] subscribe! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id SAA28968 SUBSCRIBE MOBILE-IP Xingang Liang From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 30 10:16: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 KAA24760 for ; Mon, 30 Oct 2000 10:16:21 -0500 (EST) Received: from standards (47.234.32.16:2567) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBACFB6@standards.nortelnetworks.com>; Mon, 30 Oct 2000 9:57:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 60292 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 30 Oct 2000 09:57:55 -0500 Received: from amber.novatelwireless.com (216.188.66.130:4722) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBACFB4@standards.nortelnetworks.com>; Mon, 30 Oct 2000 9:57:55 -0500 Received: by sdmail.novatelwireless.com with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Oct 2000 07:13:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04284.06B078DE" Approved-By: Rick Wietfeldt Message-ID: <7DFEB28AD03CD411808800508B134DC572F18B@sdmail.novatelwireless.com> Date: Mon, 30 Oct 2000 07:13:58 -0800 Reply-To: Rick Wietfeldt Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Rick Wietfeldt Subject: Re: [MOBILE-IP] Unsubscribe 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_01C04284.06B078DE Content-Type: text/plain; charset="iso-8859-1" Unsubscribe ------_=_NextPart_001_01C04284.06B078DE Content-Type: text/html; charset="iso-8859-1" RE: [MOBILE-IP] Unsubscribe
Unsubscribe
------_=_NextPart_001_01C04284.06B078DE-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Oct 30 17:56: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 RAA00261 for ; Mon, 30 Oct 2000 17:56:56 -0500 (EST) Received: from standards (47.234.32.16:1938) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAD1CD@standards.nortelnetworks.com>; Mon, 30 Oct 2000 17:39:14 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 60921 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 30 Oct 2000 17:39:14 -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.FFBAD1CB@standards.nortelnetworks.com>; Mon, 30 Oct 2000 17:39:13 -0500 Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id 57A321FE; Mon, 30 Oct 2000 17:54:59 -0500 (EST) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 4AFCF3A8; Mon, 30 Oct 2000 17:54:59 -0500 (EST) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Oct 2000 17:54:58 -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" Message-ID: Date: Mon, 30 Oct 2000 17:54:46 -0500 Reply-To: "Powell, Ken" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Powell, Ken" Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: "charliep@IPRG.NOKIA.COM" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Charlie, > Hello John, > > > Your suggestion: > > > - Require that a home agent's router advertisements always > contain all > > of the prefixes on the network that are valid for home or > CO addresses. > > seems to solve the problem with least harm. I particularly think > it compares well with another alternative which was suggested, > according to which the mobile node would have to assume that every > advertising home agent was its own home agent. I think the strategy > above will introduce less traffic on the wireless link. This will also simplify the requirements in section 9.7 of draft-ietf-mobileip-ipv6-12.txt. Specifically: "The home agent determines these conditions based on its own configuration as a router AND BASED ON THE ROUTER ADVERTISEMENTS THAT IT RECEIVES ON THE HOME LINK." The part in caps implies significant extra work on the part of the mobile agent to track what other routers on the home subnet advertise and relay that information to the mobile nodes. If you adopt John's proposal, would it make sense to remove this requirement? > > I also agree with previous statements that renumbering should happen > gently. In the context of your suggestion, this would mean that the > deprecated prefix would be carried by agent advertisements for quite > a while. I think that whatever is specified in the Neighbor Discovery > draft SHOULD cover the required time durations for deprecated > addresses, > but I didn't go check the wording before sending this message. If it > is not sufficient there, then we should make some explicit parameter > value specifications in the Mobile IPv6 draft. Default valid address lifetime in the ND spec is 30 days, preferred lifetime is 7 days. This implies to me that if I start a renumbering process today, I can reasonably expect that no system will be configured with the old addresses after 30 days when the valid lifetimes expire. This makes sense for the gentle renumbering approach. But I would not build a product to always rely on gentle. There is another option. The ND and stateless address autoconfiguration specs allow renumbering to happen in two hours without IPsec, and less with IPsec. Of course deleting addresses abruptly like this will disrupt the network, but I don't think that is always a bad thing. For example, I'm not worried about service disruption when I renumber the network in my lab or my home, I just want to get the job done quickly and hopefully easily. IMHO, mobile IPv6 should handle: 1) Careful renumbering, takes a month, minimal disruption to applications and users. 2) Quick renumbering, short period of network down time expected. Existing connections will fail, but can be re-established with little effort. > > Of course, the danger here is that the network could be > misconfigured so > > that home agents are not advertising all prefixes. This would be > > sub-optimal (mobility would be uses when it is not needed), > but wouldn't > > prevent the mobile node from communicating. > > A lot of things can go wrong if the network is misconfigured! > > Maybe we can put mandatory requirements in the draft so that such > misconfigurations go against explicitly stated MUSTs. Your help > in determining some correct wording would be appreciated. Using words like MUST on network configurations seems odd to me. Would it make sense to state configuration limitations as a fact; then, mandate that home agents MUST (SHOULD?) check for inconsistencies in received router advertisements and report any errors? Ken From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 31 04:08: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 EAA17489 for ; Tue, 31 Oct 2000 04:08:03 -0500 (EST) Received: from standards (47.234.32.16:3476) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAD413@standards.nortelnetworks.com>; Tue, 31 Oct 2000 3:50:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 61649 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 31 Oct 2000 03:50:02 -0500 Received: from smtp4.cluster.oleane.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAD411@standards.nortelnetworks.com>; Tue, 31 Oct 2000 3:50:02 -0500 Received: from oleane (dyn-1-1-204.Vin.dialup.oleane.fr [195.25.4.204]) by smtp4.cluster.oleane.net with SMTP id KAA53736 for ; Tue, 31 Oct 2000 10:05:50 +0100 (CET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C04322.962F3880" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Approved-By: Peter Lewis Message-ID: <001e01c0431a$34a4cc40$8001a8c0@oleane.com> Date: Tue, 31 Oct 2000 10:08:59 +0100 Reply-To: Peter Lewis Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Peter Lewis Subject: [MOBILE-IP] The first MPLS exhibition To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C04322.962F3880 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The first MPLS exhibition ever organized will take place during MPLS = World in Paris.=20 Three exhibiting options are available. Please visit: http://www.upperside.fr/congress/exhi.htm ------=_NextPart_000_001B_01C04322.962F3880 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The first MPLS exhibition ever = organized will take=20 place during MPLS World
in Paris.
Three exhibiting options are=20 available.
Please visit:
http://www.upperside.f= r/congress/exhi.htm
------=_NextPart_000_001B_01C04322.962F3880-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 31 08:53: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 IAA09441 for ; Tue, 31 Oct 2000 08:53:27 -0500 (EST) Received: from standards (47.234.32.16:4823) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAD632@standards.nortelnetworks.com>; Tue, 31 Oct 2000 8:35:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 62349 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 31 Oct 2000 08:35:40 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAD630@standards.nortelnetworks.com>; Tue, 31 Oct 2000 8:35: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 FAA08423; Tue, 31 Oct 2000 05:51:27 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9VDpPs29067; Tue, 31 Oct 2000 05:51:25 -0800 X-Virus-Scanned: Tue, 31 Oct 2000 05:51:25 -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) smtpdSQye5A; Tue, 31 Oct 2000 05:51:20 PST X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: charliep@IPRG.NOKIA.COM Message-ID: <39FECE59.5FFBD9DB@iprg.nokia.com> Date: Tue, 31 Oct 2000 05:51:21 -0800 Reply-To: "Charles E. Perkins" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Charles E. Perkins" Organization: Nokia Research Center Subject: Re: [MOBILE-IP] WGLastCall-(draft-ietf-mobileip-reg-tunnel-03.txt) X-To: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" X-cc: Satwant Kaur , Annika.Jonsson@era.ericsson.se, Eva Gustafsson To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Tom, 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 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. 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. Regards, Charlie P. > 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 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 31 10: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 KAA14974 for ; Tue, 31 Oct 2000 10:42:19 -0500 (EST) Received: from standards (47.234.32.16:4679) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAD82F@standards.nortelnetworks.com>; Tue, 31 Oct 2000 10:23:50 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 62965 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 31 Oct 2000 10:23: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.FFBAD82D@standards.nortelnetworks.com>; Tue, 31 Oct 2000 10:23:48 -0500 Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id 6805C482; Tue, 31 Oct 2000 10:39:37 -0500 (EST) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 4FBA85F7; Tue, 31 Oct 2000 10:39:37 -0500 (EST) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Tue, 31 Oct 2000 10: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" Message-ID: Date: Tue, 31 Oct 2000 10:39:09 -0500 Reply-To: "Powell, Ken" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Powell, Ken" Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: "John F. Leser" X-cc: ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Sorry for the delay, still catching up on this thread. > -----Original Message----- > From: John F. Leser [mailto:jfl@iol.unh.edu] > Sent: Wednesday, October 18, 2000 11:11 AM > To: Thomas Eklund > Cc: Francis Dupont; MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; > ipng@sunroof.eng.sun.com > Subject: Re: [MOBILE-IP] MIPv6 node location detection > - Require that a home agent's router advertisements always contain all > of the prefixes on the network that are valid for home or CO > addresses. I like the idea and think it makes sense for stateless address autoconfiguration, but how would it work with other address configuration methods like DHCPv6? Does this put restrictions on where DHCPv6 could be used? From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 31 10:55: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 KAA20944 for ; Tue, 31 Oct 2000 10:55:20 -0500 (EST) Received: from standards (47.234.32.16:4679) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAD8B2@standards.nortelnetworks.com>; Tue, 31 Oct 2000 10:38:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 63134 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 31 Oct 2000 10:38:04 -0500 Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAD8B0@standards.nortelnetworks.com>; Tue, 31 Oct 2000 10:38:03 -0500 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA11008 for ; Tue, 31 Oct 2000 08:53:48 -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 IAA15023 for ; Tue, 31 Oct 2000 08:53:47 -0700 (MST)] Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Tue, 31 Oct 2000 09:53:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Approved-By: Roberts Philip-qa3445 Message-ID: Date: Tue, 31 Oct 2000 09:53:46 -0600 Reply-To: Roberts Philip-qa3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Philip-qa3445 Subject: Re: [MOBILE-IP] san diego reminder To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, as you know you've got to submit your draft before Nov 17. You probably also know the working group agendas are due at the start of December, but we'd like to hear about it before then. Raj and I will agree on a date beyond which we won't take requests and let you know. Phil > ---------- > From: Jonathan Trostle > Sent: Friday, October 27, 2000 6:43 AM > To: Roberts Philip-qa3445; MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Cc: jtrostle@cisco.com > Subject: Re: [MOBILE-IP] san diego reminder > > I have a draft in this area that I will submit before Nov. 17. What is the deadline for submitting a request for a slot? > > Thanks, > Jonathan > > At 03:10 PM 10/26/00 -0500, Roberts Philip-qa3445 wrote: > >Hi folks, > > > > just a reminder that we're taking requests for slots in the Mobile IP > >meeting. Let us know the name of the presenter, the name of > >the I-D, and the amount of time requested. > > > >Thanks, > >Phil > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 31 12:20: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 MAA24530 for ; Tue, 31 Oct 2000 12:20:57 -0500 (EST) Received: from standards (47.234.32.16:4679) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBADA53@standards.nortelnetworks.com>; Tue, 31 Oct 2000 12:00:33 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 63652 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 31 Oct 2000 12:00:32 -0500 Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBADA51@standards.nortelnetworks.com>; Tue, 31 Oct 2000 12:00:32 -0500 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id KAA24944 for ; Tue, 31 Oct 2000 10:16:21 -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 KAA21365 for ; Tue, 31 Oct 2000 10:16:21 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Tue, 31 Oct 2000 11:16:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Approved-By: Roberts Philip-qa3445 Message-ID: Date: Tue, 31 Oct 2000 11:16:17 -0600 Reply-To: Roberts Philip-qa3445 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Roberts Philip-qa3445 Subject: Re: [MOBILE-IP] san diego reminder To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM We'd like to have all requests by Nov 17 the cutoff date for new drafts. But we'll consider requests up to Nov 29th. That will give Raj and I a little time to coordinate before we send in the agenda for the agenda cutoff date. Of course we always leave a little time for agenda bashing at the start of the meeting. > ---------- > From: Jonathan Trostle > Sent: Friday, October 27, 2000 6:43 AM > To: Roberts Philip-qa3445; MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Cc: jtrostle@cisco.com > Subject: Re: [MOBILE-IP] san diego reminder > > I have a draft in this area that I will submit before Nov. 17. What is the deadline for submitting a request for a slot? > > Thanks, > Jonathan > > At 03:10 PM 10/26/00 -0500, Roberts Philip-qa3445 wrote: > >Hi folks, > > > > just a reminder that we're taking requests for slots in the Mobile IP > >meeting. Let us know the name of the presenter, the name of > >the I-D, and the amount of time requested. > > > >Thanks, > >Phil > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 31 13:28: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 NAA21878 for ; Tue, 31 Oct 2000 13:28:44 -0500 (EST) Received: from standards (47.234.32.16:4679) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBADB85@standards.nortelnetworks.com>; Tue, 31 Oct 2000 13:10:55 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 64035 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 31 Oct 2000 13:10:55 -0500 Received: from zmamail05.zma.compaq.com (mailout.zma.compaq.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBADB83@standards.nortelnetworks.com>; Tue, 31 Oct 2000 13:10:54 -0500 Received: by zmamail05.zma.compaq.com (Postfix, from userid 12345) id EB70A5AA8; Tue, 31 Oct 2000 13:26:41 -0500 (EST) Received: from exctay-gh01.tay.cpqcorp.net (exctay-gh01.tay.cpqcorp.net [16.103.129.42]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id AD63D37F0; Tue, 31 Oct 2000 13:26:41 -0500 (EST) Received: by exctay-gh01.tay.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Tue, 31 Oct 2000 13:26:41 -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" Message-ID: Date: Tue, 31 Oct 2000 13:26:38 -0500 Reply-To: "Powell, Ken" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Powell, Ken" Subject: Re: [MOBILE-IP] MIPv6 node location detection X-To: "John F. Leser" , "ipng@sunroof.eng.sun.com" , "Charles E. Perkins" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Following upon a comment I made yesterday about John Leser's proposal... > > - Require that a home agent's router advertisements always > > contain all of the prefixes on the network that are valid > > for home or CO addresses. > Would it make sense to state configuration limitations as > a fact; then, mandate that home agents MUST (SHOULD?) check > for inconsistencies in received router advertisements and > report any errors? I was thinking that in addition to the consistency checks required by RFC 2461 section 6.2.7, the following specific checks SHOULD be made on a home agent when it receives a Router Advertisement on the home subnet: 1) If the M or O flag is set in the received Router Advertisement, verify the corresponding bit is set in the home agents own router advertisements. 2) Verify all prefixes received in the Prefix Information option are included in the home agent's own AdvPrefixList. 3) If the value of the L or A flag of a received prefix is set, verify the corresponding flag in the home agent's AdvPrefixList is also set. The R flag in received Prefix Information option should be ignored by the home agent. Any inconsistencies SHOULD be logged to system or network management. Ken From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Oct 31 22:22: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 WAA10513 for ; Tue, 31 Oct 2000 22:22:02 -0500 (EST) Received: from standards (47.234.32.16:2717) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBADF47@standards.nortelnetworks.com>; Tue, 31 Oct 2000 22:04:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 65335 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 31 Oct 2000 22:04:14 -0500 Received: from fridge.docomo-usa.com (216.98.102.228:57454) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBADF45@standards.nortelnetworks.com>; Tue, 31 Oct 2000 22:04:13 -0500 Received: from NTTD2GMTPW5TAN (dhcp24.docomo-usa.com [172.21.96.24]) by fridge.docomo-usa.com (Postfix) with SMTP id 5726A7F801; Tue, 31 Oct 2000 19:21:35 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C0436F.7219ACD0" 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: Johnny Matta Message-ID: <001701c043b2$804921d0$186015ac@NTTD2GMTPW5TAN> Date: Tue, 31 Oct 2000 19:19:10 -0800 Reply-To: Johnny Matta Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Johnny Matta Subject: [MOBILE-IP] Integration of Mobile IP and MPLS - Issues and Current Work X-cc: mpls@uu.net To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C0436F.7219ACD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, This is to ask for references on the integration of Mobile IP and MPLS = in terms of analysis of issues and current work. Has there been more = documents besides the draft "Integration of Mobile IP and MPLS" = ? Thank you. Johnny M MATTA Research Engineer DoCoMo Communications Laboratories USA, Inc. Email: matta@dcl.docomo-usa.com Phone: 1-408-451-4727 Fax: 1-408-573-1090 181 Metro Drive Suite 300 San Jose, CA 95110 ------=_NextPart_000_0014_01C0436F.7219ACD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hello,
 
This is to ask for references on the = integration of=20 Mobile IP and MPLS in terms of analysis of issues and current work. Has = there=20 been more documents besides the draft "Integration of Mobile IP and MPLS"=20 <draft-zhong-mobile-ip-mpls-01.txt>?
 
Thank you.
 
Johnny M MATTA
Research = Engineer
DoCoMo=20 Communications Laboratories USA, Inc.
Email: matta@dcl.docomo-usa.com
Phone:=20 1-408-451-4727
Fax: 1-408-573-1090
181 Metro Drive Suite = 300
San Jose,=20 CA 95110
------=_NextPart_000_0014_01C0436F.7219ACD0--