From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Feb 1 16:06:16 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11572 for ; Thu, 1 Feb 2001 16:06:15 -0500 (EST) Received: from standards (47.234.32.16:3540) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD22ED@standards.nortelnetworks.com>; Thu, 1 Feb 2001 15:43:32 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29052 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 1 Feb 2001 15:43:31 -0500 Received: from mgw-dax2.ext.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD22EB@standards.nortelnetworks.com>; Thu, 1 Feb 2001 15:43:31 -0500 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f11L5Nw06891 for ; Thu, 1 Feb 2001 15:05:23 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 1 Feb 2001 15:03:56 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id <1BRS5LJS>; Thu, 1 Feb 2001 15:03:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Approved-By: Basavaraj.Patil@NOKIA.COM Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B0337332D@daeis07nok> Date: Thu, 1 Feb 2001 14:59:16 -0600 Reply-To: Basavaraj.Patil@nokia.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] all IP on 3gpp: MIPv6 X-To: Pietro.Biasci@tei.ericsson.se To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I am not sure of the reasons for not including MobileIPv6 as being supported in 3GPP R5. Hopefully someone from 3GPP can shed some light on this. I do believe that ensuring MobileIPv6 support in the architecture (R5) will enable the UMTS network to support users/clients whose end-devices have mobile-ip built in. If MobileIPv6 does indeed become commonly implemented on end-systems they would be able to take advantage of MIPv6 support in UMTS R5 networks. -Basavaraj > -----Original Message----- > From: ext Pietro Biasci (TEI) [mailto:Pietro.Biasci@tei.ericsson.se] > Sent: Friday, January 19, 2001 7:05 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] all IP on 3gpp: MIPv6 > Importance: High > > > Hi all, > > While 3GPP selected IPv6 as mandatory for IP Multimedia, it > seems that 3GPP IMS architectures are neglecting for the moment > MIPv6 (see for example 3G TS 23.228), I think for some > different reasons (such as SIP location and mobility > management built-in features), but I cannot completely understand why. > > In fact for the 3GPP Release 5, I was not able to find in > 3GPP recent discussions about MIPv6 or TR/TS about > that...MIPv6 seems out of scope, but I'm not sure it's a so > good technical decision, if it is. > > Are you (or anybody of the list) able to clearly explain 3GPP > technical viewpoint about MIPv6 in a Multimedia environment ? > > Interesting is also 3GPP2 point of view and timeframe. > > BR, /Pietro > > ERICSSON/// > Pietro Biasci > UMTS IP Networking > E-mail * Pietro.Biasci@tei.ericsson.se > > -----Original Message----- > From: Dolan, Michael F (Mike) [mailto:mfdolan@lucent.com] > Sent: Friday, January 19, 2001 6:28 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] all IP on 3gpp > > > Jaime, > > Hi! I am the vice-chair of the 3GPP2 All-IP Group. > > Please be assured that 3GPP2 certainly intends to support IPv6. That > decision is already written into our adopted Requirements > document. Mobile > IP and specifically Mobile IPv6 have been at the core of many > discussions > for the last year or more, and are a basic tenet in our ongoing work. > > 3GPP2 already has IPv4 (and Mobile IPv4) built into its > standards. Members > of 3GPP2 TSG-P (Tom Hiller, Pat Calhoun, Pete McCann, Mark > Lipford, and > others) have been working closely with the Mobile IP WG for > some time now to > add needed extensions to Mobile IPv4 to support wireless environments. > Since Mobile IPv4 is already a foundation block of 3GPP2 > systems, 3GPP2 > cannot abandon IPv4. Instead, an evolutionary path that > moves 3GPP2 systems > as quickly as possible to IPv6 is a hot work item. > > Your list of issues is a good one. It matches many similar > lists held by > others. > > I suggest that if you (or others) wish to continue this > discussion, please > contact me directly. That will help keep this email list for > more technical > topics. > > Thanks for your question. > > Have a good day, > Mike Dolan > 3GPP2 All-IP Vice-Chair > Lucent Technologies > mfdolan@lucent.com > PH +1.630.979.1033 > Mob +1.630.697.3549 > > > > -----Original Message----- > From: Jaime Dias [mailto:jdias@inescporto.pt] > Sent: Thursday, January 18, 2001 6:02 AM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: [MOBILE-IP] all IP on 3gpp > > > Hi! > > I'm studying scenarios for the ALL IP in an UMTS environment. > I've already see some approach with Cellular IPv6 and/or > MIPv6, but that's > where the confusion begin: > Some approach byu 3G.IP refers about an MIP to the RNC. > Until now the IP between the UE and the RNC are > tunnelled, so, where the > Cellular IP take place? > > In respect of the advantages of an IPv6 ALL IP, "I think" > that it don't rest > many doubts: > Mobility as an inherent feature > Route optimisation > MIPv6 includes features to minimize loss in-flight packets during > handover > No foreign agents need to be deployed. > Address space. > QoS > Security > > So, can anybody tell me why the 3GPP2 are so reluctant about the IPv6? > > I would be very thankful. > > Jaime Dias > __________________________________________ > Jaime Sousa Dias > INESC Porto > fone.: +351 22 2094258 > fax:+351 22 2084172 > Telecom & Multimedia Unit > Porto, Portugal > http://www.inescporto.pt/ > http://telecom.inescn.pt > __________________________________________ > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 2 03:24:27 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04901 for ; Fri, 2 Feb 2001 03:24:26 -0500 (EST) Received: from standards (47.234.32.16:3673) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD2859@standards.nortelnetworks.com>; Fri, 2 Feb 2001 3:02:00 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30897 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Feb 2001 03:01:59 -0500 Received: from ms.hansol.co.kr (210.112.2.207:2780) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD2857@standards.nortelnetworks.com>; Fri, 2 Feb 2001 3:01:58 -0500 Received: from ns ([211.113.87.7]) by ms.hansol.co.kr (8.9.3/8.9.3) with SMTP id RAA11751 for ; Fri, 2 Feb 2001 17:18:53 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Approved-By: Jiwoong Lee Message-ID: <003801c08cf1$6a5f2080$d012060a@hansol.co.kr> Date: Fri, 2 Feb 2001 17:22:53 +0900 Reply-To: Jiwoong Lee Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jiwoong Lee Subject: [MOBILE-IP] IPv6 Mobile router again, for multicast To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id DAA04901 I've browsed the previous discussion in this ML for IPv6 mobile router. Before resolving the unicast problem, MobileIPv6 ID-ver13 seems to block any possibility to support a IPv6 mobile multicast router. I'm not clear enough about this. Anyone can give me some background explanation? Jiwoong. Please refer: Multicast packets addressed to a multicast address with link-local scope [9], to which the mobile node is subscribed, MUST NOT be tunneled to the mobile node; such packets SHOULD be silently discarded (after delivering to other local multicast recipients). (pp.68) From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 2 04:04:16 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA05161 for ; Fri, 2 Feb 2001 04:04:15 -0500 (EST) Received: from standards (47.234.32.16:3865) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD28D6@standards.nortelnetworks.com>; Fri, 2 Feb 2001 3:43:20 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31056 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Feb 2001 03:43:19 -0500 Received: from mailhost.tbit.dk (mailhostnew.tbit.dk) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD28D4@standards.nortelnetworks.com>; Fri, 2 Feb 2001 3:43:18 -0500 Received: from ted.ericsson.dk (IDENT:root@mailhost.tbit.dk [194.182.135.150]) by mailhost.tbit.dk (8.9.3/8.9.3) with ESMTP id KAA31740; Fri, 2 Feb 2001 10:03:51 +0100 X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.15-4mdk i686) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: petg@ERICSSONTELEBIT.COM Message-ID: <3A7A77F7.B2FB6D@ted.ericsson.dk> Date: Fri, 2 Feb 2001 10:03:51 +0100 Reply-To: Peter Grimstrup Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Peter Grimstrup Organization: Ericsson Telebit A/S Subject: [MOBILE-IP] Comments on draft-ietf-mobileip-ipv6-13.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit 1. Section 4.2 New IPv6 Destination Options under Binding Update says: "The Binding Update option and its specific IPsec requirements are described in detail in Section 5.1." The IPsec stuff has been moved to Section 4.4 - this comment apply to the subsections on Binding Acknowledgement and Home Address as well. 2. According to Section 5.4 Home Address Option the Home Address Option MUST be placed after the Routing Header and before the Fragment Header. Does this imply that three Destination Option Header Extensions are allowed or has it been moved from before the Routing Header. Peter Grimstrup -- Peter Grimstrup Systems Developer Ericsson Telebit A/S tel: +45 89 38 52 75 Skanderborgvej 232 fax: +45 89 38 51 01 DK 8260 Viby J, Denmark e-mail: peter.grimstrup@ted.ericsson.dk From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Feb 2 14:59:37 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25022 for ; Fri, 2 Feb 2001 14:59:36 -0500 (EST) Received: from standards (47.234.32.16:2687) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD2D31@standards.nortelnetworks.com>; Fri, 2 Feb 2001 14:37:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32478 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Feb 2001 14:37:10 -0500 Received: from rajma.kniveton.com (adsl-63-197-0-77.dsl.snfc21.pacbell.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD2D2E@standards.nortelnetworks.com>; Fri, 2 Feb 2001 14:37:09 -0500 Received: from [192.168.1.42] (qool.kniveton.com [192.168.1.42]) by rajma.kniveton.com (8.11.1/8.11.1) with ESMTP id f12Jv4a67413; Fri, 2 Feb 2001 11:57:04 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Approved-By: "T.J. Kniveton" Message-ID: Date: Fri, 2 Feb 2001 11:57:39 -0800 Reply-To: "T.J. Kniveton" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "T.J. Kniveton" Subject: Re: [MOBILE-IP] IPv6 Prefix Deprecation Problem X-To: Matt Crawford X-cc: ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200102021541.JAA11329@gungnir.fnal.gov> Content-Transfer-Encoding: 7bit [I am crossposting to Mobile-IP since I am throwing in some info about mobiles] on 2/2/01 7:41 AM, Matt Crawford wrote: > Is it OK with everyone that a node that has been turned off for a while, > could possibly be *unusable* on a network for two hours? We can not say > > I think "unusuable" is too strong. There will presumably be newer > prefixes advertised and no rule makes the node ignore those. OK, here is why I posted the message. We can certainly imagine good implementations that handle this renumbering case without a hitch. However, in reading the rules of the draft, I can imagine correct, and possibly even reasonable, implementations that choke at this point. For instance, if my implementation has a strong affinity for my primary global address as long as it remains valid, and it thinks the address is valid for a couple more hours, it might continue to try to use that address. Some layer above IP is choosing the source address -- either the application, or an upper network layer on its behalf. This layer "should" [2462] choose a prefix that has a positive preferred lifetime remaining when it opens a connection. Perhaps that "should" should change to "must". What bothers me boils down to the fact that we have a VALID prefix, though it may not be preferred. A deprecated address is still a valid address and MAY be used to start new communication. Yet the autoconfig rules do not have any way to remove this invalid address/prefix. > > Also, doesn't the node's stack need to allow for the possibility that > when it is powered back on, it is connected to a different link entirely? Good point. I didn't even get into the problems with mobile nodes. Imagine, for instance the following twist: The mobile node had one global address based on its home prefix. It was turned off on July 31st. The mobile's Home Network was renumbered, as described in RFC 2461, between August 1st and September 1st. Mappings from the old prefix to the new prefix were removed from routers on September 15th. The old prefix is dead. Now the mobile node is turned on, on September 25th, in a visited network. It starts receiving router advertisements for the local link. It configures a link-local care-of address. It wants to contact its Home Agent to register a binding for its care-of address. "I can't contact my home agent." "I can't contact any routers on my home network to do Home Agent Discovery." "My cached home address has not expired...but my home network has disappeared." "Help!" Hmmm. This could be a problem. I am writing a draft to address possible courses of action at this point..unless anyone can provide a good, clear, obvious answer. -- TJ Kniveton NOKIA Research From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Feb 3 16:41:11 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12363 for ; Sat, 3 Feb 2001 16:41:11 -0500 (EST) Received: from standards (47.234.32.16:4272) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD3273@standards.nortelnetworks.com>; Sat, 3 Feb 2001 16:18:28 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34306 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 3 Feb 2001 16:18:28 -0500 Received: from rajma.kniveton.com (adsl-63-197-0-77.dsl.snfc21.pacbell.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD3271@standards.nortelnetworks.com>; Sat, 3 Feb 2001 16:18:27 -0500 Received: from Kniveton.com (nachos.kniveton.com [192.168.1.69]) by rajma.kniveton.com (8.11.1/8.11.1) with ESMTP id f13LcFa70892; Sat, 3 Feb 2001 13:38:15 -0800 (PST) X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <20010203053633.0DC587E46@starfruit.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: TJ@KNIVETON.COM Message-ID: <3A7C7A6B.C7EFC7E9@Kniveton.com> Date: Sat, 3 Feb 2001 13:38:51 -0800 Reply-To: "T.J. Kniveton" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "T.J. Kniveton" Organization: NOKIA Research Subject: Re: [MOBILE-IP] IPv6 Prefix Deprecation Problem X-To: Jun-ichiro itojun Hagino X-cc: ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Jun-ichiro itojun Hagino wrote: > > >Now the mobile node is turned on, on September 25th, in a visited network. > >It starts receiving router advertisements for the local link. It configures > >a link-local care-of address. It wants to contact its Home Agent to register > >a binding for its care-of address. > > link-local care-of address? are you sure you want to do that? I hope > this is typo of "global care-of address". > (note that you can only contact correspondent nodes that is on-link > to the mobile node) > > scope issue with mobile-ip6 is hairy... > > itojun You caught me typing too fast. Instead of "link-local care-of address," I meant to say simply "care-of address," which would obviously be a globally routable autoconfigured address using a prefix advertised on the visited network link. TJ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Feb 4 20:35:52 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13713 for ; Sun, 4 Feb 2001 20:35:51 -0500 (EST) Received: from standards (47.234.32.16:1654) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD3664@standards.nortelnetworks.com>; 4 Feb 2001 20:12:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35701 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 4 Feb 2001 20:12:55 -0500 Received: from ms.hansol.co.kr (210.112.2.207:4225) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD3662@standards.nortelnetworks.com>; 4 Feb 2001 20:12:54 -0500 Received: from ns ([211.113.87.7]) by ms.hansol.co.kr (8.9.3/8.9.3) with SMTP id KAA20019 for ; Mon, 5 Feb 2001 10:29:47 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Approved-By: Jiwoong Lee Message-ID: <006301c08f13$cd0ce9a0$d012060a@hansol.co.kr> Date: Mon, 5 Feb 2001 10:34:06 +0900 Reply-To: Jiwoong Lee Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jiwoong Lee Subject: [MOBILE-IP] IPv6 Mobile Router again, for Multicast To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id UAA13713 Note: This is the thirdly repeated message for ML server's erroneous processing. I've browsed the previous discussion in this ML for IPv6 mobile router. Before resolving the unicast problem, MobileIPv6 ID-ver13 seems to block any possibility to support a IPv6 mobile multicast router. I'm not clear enough about this. Anyone can give me some background explanation? Jiwoong. Please refer: Multicast packets addressed to a multicast address with link-local scope [9], to which the mobile node is subscribed, MUST NOT be tunneled to the mobile node; such packets SHOULD be silently discarded (after delivering to other local multicast recipients). (pp.68) From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Feb 4 20:59:15 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13896 for ; Sun, 4 Feb 2001 20:59:15 -0500 (EST) Received: from standards (47.234.32.16:1654) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD36CC@standards.nortelnetworks.com>; 4 Feb 2001 20:36:52 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35826 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 4 Feb 2001 20:36:51 -0500 Received: from m018.com (210.112.11.138:4116) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD36C1@standards.nortelnetworks.com>; 4 Feb 2001 20:26:50 -0500 Received: from mail pickup service by m018.com with Microsoft SMTPSVC; Mon, 5 Feb 2001 10:24:22 +0900 Received: from patan.sun.com ([192.18.98.43]) by m018.com with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 5 Feb 2001 09:56:06 +0900 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24783; Sat, 3 Feb 2001 13:41:52 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18099; Sat, 3 Feb 2001 13:41:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f13LdHH25328 for ipng-dist; Sat, 3 Feb 2001 13:39:17 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f13Ld7225321 for ; Sat, 3 Feb 2001 13:39:08 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17992 for ; Sat, 3 Feb 2001 13:39:06 -0800 (PST) Received: from rajma.kniveton.com (adsl-63-197-0-77.dsl.snfc21.pacbell.net [63.197.0.77]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23771 for ; Sat, 3 Feb 2001 13:39:05 -0800 (PST) Received: from Kniveton.com (nachos.kniveton.com [192.168.1.69]) by rajma.kniveton.com (8.11.1/8.11.1) with ESMTP id f13LcFa70892; Sat, 3 Feb 2001 13:38:15 -0800 (PST) X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <20010203053633.0DC587E46@starfruit.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Approved-By: owner-ipng@SUNROOF.ENG.SUN.COM Message-ID: <3A7C7A6B.C7EFC7E9@Kniveton.com> Date: Sat, 3 Feb 2001 13:38:51 -0800 Reply-To: "T.J. Kniveton" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "T.J. Kniveton" Organization: NOKIA Research Subject: Re: [MOBILE-IP] IPv6 Prefix Deprecation Problem X-To: Jun-ichiro itojun Hagino X-cc: ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Jun-ichiro itojun Hagino wrote: > > >Now the mobile node is turned on, on September 25th, in a visited network. > >It starts receiving router advertisements for the local link. It configures > >a link-local care-of address. It wants to contact its Home Agent to register > >a binding for its care-of address. > > link-local care-of address? are you sure you want to do that? I hope > this is typo of "global care-of address". > (note that you can only contact correspondent nodes that is on-link > to the mobile node) > > scope issue with mobile-ip6 is hairy... > > itojun You caught me typing too fast. Instead of "link-local care-of address," I meant to say simply "care-of address," which would obviously be a globally routable autoconfigured address using a prefix advertised on the visited network link. TJ -------------------------------------------------------------------- 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 Mon Feb 5 04:23:17 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02609 for ; Mon, 5 Feb 2001 04:23:16 -0500 (EST) Received: from standards (47.234.32.16:3119) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD38E1@standards.nortelnetworks.com>; Mon, 5 Feb 2001 4:00:38 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36548 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 5 Feb 2001 04:00:37 -0500 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD38DF@standards.nortelnetworks.com>; Mon, 5 Feb 2001 4:00:37 -0500 Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f159LAC13901; Mon, 5 Feb 2001 10:21:14 +0100 (MET) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id KAA29719; Mon, 5 Feb 2001 10:21:10 +0100 X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en, sv MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Mattias Pettersson Message-ID: <3A7E6C58.55A01CA@era.ericsson.se> Date: Mon, 5 Feb 2001 10:03:20 +0100 Reply-To: Mattias Pettersson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mattias Pettersson Organization: Ericsson Radio Systems AB Subject: Re: [MOBILE-IP] IPv6 Prefix Deprecation Problem X-To: "T.J. Kniveton" X-cc: Matt Crawford , ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit "T.J. Kniveton" wrote: > > [I am crossposting to Mobile-IP since I am throwing in some info about > mobiles] > > > > Also, doesn't the node's stack need to allow for the possibility that > > when it is powered back on, it is connected to a different link entirely? > > Good point. I didn't even get into the problems with mobile nodes. Imagine, > for instance the following twist: > > The mobile node had one global address based on its home prefix. It was > turned off on July 31st. The mobile's Home Network was renumbered, as > described in RFC 2461, between August 1st and September 1st. Mappings from > the old prefix to the new prefix were removed from routers on September > 15th. The old prefix is dead. > > Now the mobile node is turned on, on September 25th, in a visited network. > It starts receiving router advertisements for the local link. It configures > a link-local care-of address. It wants to contact its Home Agent to register > a binding for its care-of address. > > "I can't contact my home agent." > "I can't contact any routers on my home network to do Home Agent Discovery." > "My cached home address has not expired...but my home network has > disappeared." > "Help!" > > Hmmm. This could be a problem. I am writing a draft to address possible > courses of action at this point..unless anyone can provide a good, clear, > obvious answer. Are your prefix lifetimes not supposed to be in the same order as the renumbering period? If your renumbering takes one month, set valid lifetime to one month for prefixes announces long before the renumbering phase starts. In this way you won't end up in situations like this. Next, I wouldn't be sure that a Mobile Node would remember it's home prefix lifetime if it was switched off. One requirement that we came up to when writing Mobile IPv6 i-d v13 was that the Mobile Node must somehow know its home prefix or a DNS name representing the home prefix or home agents anycast address. How the Mobile Node learns this is out of scope of the draft. Thus, the upper layer that provides the Mobile Node with the home prefix in the first place, must also provide the new renumbered home prefix in cases like this when the Mobile Node is switched off during renumbering. /Mattias From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 5 05:15:18 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02913 for ; Mon, 5 Feb 2001 05:15:17 -0500 (EST) Received: from standards (47.234.32.16:4856) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD39A5@standards.nortelnetworks.com>; Mon, 5 Feb 2001 4:52:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36810 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 5 Feb 2001 04:52:45 -0500 Received: from hotmail.com (law2-f67.hotmail.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD39A3@standards.nortelnetworks.com>; Mon, 5 Feb 2001 4:52:44 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 5 Feb 2001 02:13:27 -0800 Received: from 163.221.99.203 by lw2fd.hotmail.msn.com with HTTP; Mon, 05 Feb 2001 10:13:27 GMT X-Originating-IP: [163.221.99.203] Mime-Version: 1.0 Content-Type: text/html X-OriginalArrivalTime: 05 Feb 2001 10:13:27.0492 (UTC) FILETIME=[480C9040:01C08F5C] Approved-By: Jonathan Khoo Message-ID: Date: Mon, 5 Feb 2001 18:13:27 +0800 Reply-To: Jonathan Khoo Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jonathan Khoo Subject: Re: [MOBILE-IP] Who implements MIP? To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM

Hi,

There is an implementation of MIPv6 BSD platform from Ericsson. It has been merged in the KAME project.

http://www.kame.net

By the way, does anyone knows where to get the source for Hierarchical MIPv6 by INRIA? The link in the homepage does not work.

Cheers,
Jonathan

>From: "Finney, Joe"
>Reply-To: "Finney, Joe"
>To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
>Subject: Re: [MOBILE-IP] Who implements MIP?
>Date: Wed, 31 Jan 2001 11:31:40 -0000
>
>Hi,
>
> > First of all, I am sorry if this is a repeat question for some/most of
> > you.
> > I have been unable to access the archive over the web (May be the IEEE
> > pages point to the wrong address!)
> >
> > Does anyone know who implement Mobile IP in their products? My guess
> > is that the v4 version is implemented. Does anyone do v6? Is anyone
> > implementing the route optimization extensions?
> >
> > Thanks for all your help.
> >
>
>For info, as part of the LandMARC project we've been developing a Mobile IPv6
>implementation (mobile node, correspondent node and home agent) for Windows in
>collaboration with Microsoft Research. The code currently runs on Windows NT
>and Windows 2000 and we're planning to look at CE in the near future.
>
>The code has just gone to public release a few weeks ago, so you can download
>it and try it out if you like. See http://www.LandMARC.net for more info.
>
>We also have a Linux implementation which we're currently bringing up to date,
>which will be released in the next month or so.
>
>Thanks,
>Joe
>--------------------------------------------------------------------
>Dr. Joe Finney e-mail: joe@comp.lancs.ac.uk
>Computing Dept, tel: (+44) (0)1524 592732
>Faculty of Applied Sciences,
>Lancaster University,
>Lancaster, fax: (+44) (0)1524 593608
>UK. www: http://www.comp.lancs.ac.uk/
> computing/staff/joe
>LA1 4YR
>---------------------------------------------------------------------

Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 5 06:11:17 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03212 for ; Mon, 5 Feb 2001 06:11:17 -0500 (EST) Received: from standards (47.234.32.16:3077) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD3A22@standards.nortelnetworks.com>; Mon, 5 Feb 2001 5:48:51 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36965 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 5 Feb 2001 05:48:51 -0500 Received: from ebene.inrialpes.fr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD3A20@standards.nortelnetworks.com>; Mon, 5 Feb 2001 5:48:51 -0500 Received: from glandon.inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.9.3/8.8.6) with ESMTP id MAA15707; Mon, 5 Feb 2001 12:09:23 +0100 (MET) Received: from inrialpes.fr (localhost [127.0.0.1]) by glandon.inrialpes.fr (8.8.7/8.8.5) with ESMTP id MAA12989; Mon, 5 Feb 2001 12:09:22 +0100 (MET) X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <006301c08f13$cd0ce9a0$d012060a@hansol.co.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Thierry.Ernst@INRIALPES.FR Message-ID: <3A7E89E2.57F80748@inrialpes.fr> Date: Mon, 5 Feb 2001 12:09:22 +0100 Reply-To: Thierry Ernst Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Thierry Ernst Organization: INRIA Rhone-Alpes Subject: Re: [MOBILE-IP] IPv6 Mobile Router again, for Multicast X-cc: Jiwoong Lee To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Jiwoong, I cannot reply about Multicast. What is sure is that if there are some hosts connected to your Mobile Router, they will never get any unicast packet. A mobile router basically means a mobile network or mobile subnetwork since a Router is usually serving a set of hosts. All the set is therefore moving together. Only the Mobile Router ITSELF can receive packets, not the other nodes in the mobile network. The reasons are better explained in my draft that you could find on the IETF web site http://search.ietf.org/internet-drafts/draft-ernst-mobileip-v6-network-01.txt (or alternatively on my web page together with my presentation made at last IETF). I would be happy to hear any comment from you concerning the multicast issues. Hope this helps, Thierry. Jiwoong Lee wrote: > > Note: This is the thirdly repeated message for ML server's erroneous processing. > > I've browsed the previous discussion in this ML for IPv6 mobile router. Before resolving the unicast problem, MobileIPv6 ID-ver13 seems to block any possibility to support a IPv6 mobile multicast router. I'm not clear enough about this. Anyone can give me some background explanation? > > Jiwoong. > > Please refer: > > Multicast packets addressed to a multicast address with link-local scope [9], to which the mobile node is subscribed, MUST NOT be tunneled to the mobile node; such packets SHOULD be silently discarded (after delivering to other local multicast recipients). (pp.68) -- * 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 Feb 5 11:23:47 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11015 for ; Mon, 5 Feb 2001 11:23:46 -0500 (EST) Received: from standards (47.234.32.16:4149) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD3D28@standards.nortelnetworks.com>; Mon, 5 Feb 2001 11:01:11 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37999 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 5 Feb 2001 11:01:11 -0500 Received: from ztxmail05.ztx.compaq.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD3D26@standards.nortelnetworks.com>; Mon, 5 Feb 2001 11:01:10 -0500 Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id F1FCFBB3; Mon, 5 Feb 2001 10:21:53 -0600 (CST) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 97C61ACF; Mon, 5 Feb 2001 10:21:53 -0600 (CST) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Mon, 5 Feb 2001 11:21:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain Approved-By: "Powell, Ken" Message-ID: Date: Mon, 5 Feb 2001 11:21:49 -0500 Reply-To: "Powell, Ken" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Powell, Ken" Subject: Re: [MOBILE-IP] IPv6 Prefix Deprecation Problem X-To: "T.J. Kniveton" X-cc: ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > -----Original Message----- > From: T.J. Kniveton [mailto:TJ@Kniveton.com] > Sent: Friday, February 02, 2001 2:58 PM > To: Matt Crawford > Cc: ipng@sunroof.eng.sun.com; mobile-ip@standards.nortelnetworks.com > Subject: Re: IPv6 Prefix Deprecation Problem > > Some layer above IP is choosing the source address -- either the > application, or an upper network layer on its behalf. This > layer "should" > [2462] choose a prefix that has a positive preferred lifetime > remaining when > it opens a connection. Perhaps that "should" should change to "must". There are other considerations that go into source address selection, some of which have a worse impact than selecting an address with preferred lifetime of zero. See Richard Draves' draft-ietf-ipngwg-default-addr-select-02 for more details. > > > > > Also, doesn't the node's stack need to allow for the > possibility that > > when it is powered back on, it is connected to a different > link entirely? > > Good point. I didn't even get into the problems with mobile > nodes. Imagine, > for instance the following twist: > > The mobile node had one global address based on its home > prefix. It was > turned off on July 31st. The mobile's Home Network was renumbered, as > described in RFC 2461, between August 1st and September 1st. > Mappings from > the old prefix to the new prefix were removed from routers on > September > 15th. The old prefix is dead. > > Now the mobile node is turned on, on September 25th, in a > visited network. > It starts receiving router advertisements for the local link. > It configures > a link-local care-of address. It wants to contact its Home > Agent to register > a binding for its care-of address. > > "I can't contact my home agent." > "I can't contact any routers on my home network to do Home > Agent Discovery." > "My cached home address has not expired...but my home network has > disappeared." > "Help!" I've had this same concern. We discussed it on the mobility list last year, and as Mattias said, the procedure for initializing a mobile node is beyond the scope of the Mobile IPv6 draft. We did however discuss some possible initialization techniques to verify that the mobile IPv6 protocol had sufficient features to support initialization, particularly where stateless address autoconfiguration is used on the home network. Appendix A of draft-ietf-mobileip-ipv6-13 describes one of these techniques. It starts by retrieving the home agent anycast address from DNS. One problem with the appendix A approach is that it does not account for IPsec. We need a procedure that describes how to establish the security associations between the mobile node and the home agent in addition to initializing home addresses and creating bindings. Perhaps something that uses a AAA server? > > Hmmm. This could be a problem. I am writing a draft to > address possible > courses of action at this point..unless anyone can provide a > good, clear, > obvious answer. I'm looking forward to seeing your draft. Ken From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 5 18:25:00 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20437 for ; Mon, 5 Feb 2001 18:25:00 -0500 (EST) Received: from standards (47.234.32.16:1726) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD4083@standards.nortelnetworks.com>; Mon, 5 Feb 2001 18:02:00 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39147 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 5 Feb 2001 18:01:59 -0500 Received: from mailhost.iprg.nokia.com (205.226.5.12:25479) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD407A@standards.nortelnetworks.com>; Mon, 5 Feb 2001 17:51:58 -0500 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA13078; Mon, 5 Feb 2001 15:12:42 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f15NCeg16741; Mon, 5 Feb 2001 15:12:40 -0800 X-Virus-Scanned: Mon, 5 Feb 2001 15:12:40 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdIipmf7; Mon, 05 Feb 2001 15:12:34 PST X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <034BEFD03799D411A59F00508BDF75465B6979@esealnt448.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: tkniveto@IPRG.NOKIA.COM Message-ID: <3A7F3365.9DBB43A6@Nokia.com> Date: Mon, 5 Feb 2001 15:12:37 -0800 Reply-To: "T.J. Kniveton" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "T.J. Kniveton" Organization: NOKIA Research Subject: Re: [MOBILE-IP] IPv6 Prefix Deprecation Problem X-To: ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit "Hesham Soliman (ERA)" wrote: > => I don't have a concrete proposal but basically the problem > here is manual configuration of the Home address / prefix. > If the MN can decouple its identity from the Home prefix > and use something more abstract (eg. NAI) then the > problem can be solved. > - The MN starts in a foreign network > - It discovers its home address (By looking up the > NAI is some location management database. eg DNS) > - The MN does dynamic HA discovery > - The MN sends a BU to the HA. Thanks for your input, Hesham. This alternative, similar to Appendix A of the Draft, is one of the alternatives I was considering, and probably the best event sequence when DNS will help you out and you have configured with the NAI properly. There are a couple of other possibilities, and it might be optimal to have a fallback if you can not get the home network prefix because of lack of needed services, or lack of correct configuration. > In general manually configuring the Home address seems > to be a bad approach IMO. The above approach is implementation > dependant and would not require modifications to MIPv6. Yes, it probably takes the least amount of manual intervention, which is a good thing. Mattias Pettersson wrote: > Are your prefix lifetimes not supposed to be in the same order as the > renumbering period? If your renumbering takes one month, set valid > lifetime to one month for prefixes announces long before the renumbering > phase starts. In this way you won't end up in situations like this. It may or may not be possible to have enough a priori knowledge of the renumbering to start advertising shortened lifetimes "long" before the renumbering. Regardless, wouldn't it be better to have a spec that handles possible and reasonable situations, rather than saying things will work if you implement and configure just-so? To me, it is not a far stretch of the imagination to picture a laptop that is a MN running MIPv6, which sits for a long period of time on a foreign network, and is switched off for a few months. I mean, maybe it's not the common case..but it should still work! Right? > Next, I wouldn't be sure that a Mobile Node would remember it's home > prefix lifetime if it was switched off. OK.. But if the state this machine is keeping around is its home network prefix, it could be toast. If it is keeping its home address, home agent address, and home network prefix without any lifetimes, it still may not be able to communicate with its home network or any correspondents using its home address. The lifetime is not really the problem. It's how much information and support you need to determine your identity and origins. > One requirement that we came up to when writing Mobile IPv6 i-d v13 was > that the Mobile Node must somehow know its home prefix or a DNS name > representing the home prefix or home agents anycast address. How the Well, DNS is the option that's most likely to survive a network renumbering. But, can we really mandate that DNS is available for a mobile node when it's configuring on a foreign network?... > Mobile Node learns this is out of scope of the draft. Thus, the upper Appendix A deals with it in a limited situation as Hesham denoted above. What if DNS is not available? It may also be able to continue supporting mobility at the IP layer, but without use of the Home Address, if the home network can not be resolved. I.e. what if the visited network becomes your new, temporary "home network" and you can continue to roam, keeping open TCP connections, using your COA as your "home address". Is there any interest in exploring the issue (beyond the scope of the draft, if need be)? > layer that provides the Mobile Node with the home prefix in the first > place, must also provide the new renumbered home prefix in cases like > this when the Mobile Node is switched off during renumbering. Good point. -- T.J. Kniveton NOKIA Research Center From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 5 20:45:27 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21880 for ; Mon, 5 Feb 2001 20:45:27 -0500 (EST) Received: from standards (47.234.32.16:4396) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD4144@standards.nortelnetworks.com>; Mon, 5 Feb 2001 20:22:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39396 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 5 Feb 2001 20:22:37 -0500 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD4136@standards.nortelnetworks.com>; Mon, 5 Feb 2001 20:12:36 -0500 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA27124; Mon, 5 Feb 2001 17:33:20 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f161XIO08711; Mon, 5 Feb 2001 17:33:18 -0800 X-Virus-Scanned: Mon, 5 Feb 2001 17:33:18 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Kniveton.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdmPVuq5; Mon, 05 Feb 2001 17:33:10 PST X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <7695E2F6903F7A41961F8CF888D87EA801FB4BED@red-msg-06.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: tkniveto@IPRG.NOKIA.COM Message-ID: <3A7F5457.60992CC@Kniveton.com> Date: Mon, 5 Feb 2001 17:33:11 -0800 Reply-To: "T.J. Kniveton" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "T.J. Kniveton" Organization: NOKIA Research Subject: Re: [MOBILE-IP] IPv6 Prefix Deprecation Problem X-To: Richard Draves X-cc: ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Richard Draves wrote: > > > Specifically, let's consider the scenario described in RFC > > 2461 on page > > 78-79. A prefix has been advertised with a lifetime of two months, a > > machine is turned off on July 31st, then on Aug. 1st, it's decided the > > prefix should expire on Sep 1st. The host is turned back during > > September, at which point the prefix is deprecated, but the > > node's last > > received advertisement indicates the prefix is valid until the end of > > September. > > I don't know of any implementations that keep prefixes in a persistent > store. My expectaction would be that when the host is turned back on in > September, it will send an RS and get RAs and auto-configure itself without > any memory of the old prefix. No, the mobile node is not on its home network; it is away from home. RSs sent on the VISITED link will allow auto-configuration of a COA. Getting RAs from the HOME link would require tunneling a RS to the home network. And to tunnel this RA, you need the HA's address (the first n bits of your cached copy are now bogus). Back to square 1. > Furthermore, I think the site administrator has screwed up by advertising a > two month lifetime and then trying to remove the prefix in one month. Maybe true. Which leaves the questions, why does 2462 give this as an example of network renumbering, why are lifetimes 32 bits and why does the RFC allow infinite lifetimes on network prefixes? This is academic anyway. The problem isn't necessarily that the old prefix doesn't go away fast enough. The problem is that a mobile node, away from home, may wake up from being turned off during a renumbering event, and have NO WAY to contact its home agent or even home network. Either it has stale prefix info, or NO prefix info, but with no binding at its home agent, and thus no tunneled router advertisements at any point during the renumbering, it doesn't have CURRENT prefix info. Whether the renumbering took place over a day, month, or year is immaterial - the mobile simply has to be away from home and not register with the HA when the renumbering starts, and then start using Mobile IPv6 after the network renumbering for the problem to arise. This was my original point, which perhaps I have not effectively described. There is a way around this, using DNS, but that requires services that may not be available on the visited network. I can not see a general and acceptable way to avoid this problem, but I remain open to suggestions. Thanks, -- T.J. Kniveton NOKIA Research Center From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Feb 5 23:41:15 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA25522 for ; Mon, 5 Feb 2001 23:41:14 -0500 (EST) Received: from standards (47.234.32.16:3437) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD41F1@standards.nortelnetworks.com>; Mon, 5 Feb 2001 23:18:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39639 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 5 Feb 2001 23:18:40 -0500 Received: from mail3.microsoft.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD41EF@standards.nortelnetworks.com>; Mon, 5 Feb 2001 23:18:38 -0500 Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 05 Feb 2001 20:23:28 -0800 (Pacific Standard Time) Received: by inet-imc-03.redmond.corp.microsoft.com with Internet Mail Service (5.5.2653.19) id <111G1XDX>; Mon, 5 Feb 2001 20:24:55 -0800 X-Mailer: Internet Mail Service (5.5.2653.19) Approved-By: Richard Draves Message-ID: <7695E2F6903F7A41961F8CF888D87EA801FB4C13@red-msg-06.redmond.corp.microsoft.com> Date: Mon, 5 Feb 2001 20:24:50 -0800 Reply-To: Richard Draves Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Richard Draves Subject: Re: [MOBILE-IP] IPv6 Prefix Deprecation Problem X-To: "T.J. Kniveton" X-cc: ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > I don't know of any implementations that keep prefixes in a > persistent > > store. My expectaction would be that when the host is > turned back on in > > September, it will send an RS and get RAs and > auto-configure itself without > > any memory of the old prefix. > > No, the mobile node is not on its home network; it is away from home. Ah, I didn't understand from your first message that you were asking about a mobile node's home address. I thought you were asking about ordinary auto-configured prefixes. Sorry. > > Furthermore, I think the site administrator has screwed up > by advertising a > > two month lifetime and then trying to remove the prefix in > one month. > > Maybe true. Which leaves the questions, why does 2462 give this as an > example of network renumbering, why are lifetimes 32 bits and why does > the RFC allow infinite lifetimes on network prefixes? > > This is academic anyway. The problem isn't necessarily that the old > prefix doesn't go away fast enough. The problem is that a mobile node, > away from home, may wake up from being turned off during a renumbering > event, and have NO WAY to contact its home agent or even home network. > Either it has stale prefix info, or NO prefix info, but with > no binding > at its home agent, and thus no tunneled router advertisements at any > point during the renumbering, it doesn't have CURRENT prefix info. > Whether the renumbering took place over a day, month, or year is > immaterial - the mobile simply has to be away from home and > not register > with the HA when the renumbering starts, and then start using Mobile > IPv6 after the network renumbering for the problem to arise. > > This was my original point, which perhaps I have not effectively > described. There is a way around this, using DNS, but that requires > services that may not be available on the visited network. I > can not see > a general and acceptable way to avoid this problem, but I > remain open to > suggestions. I suspect people are willing to punt on this problem (of mobile nodes away from home & turned off for an arbitrarily long time, while the home network undergoes arbitrary reconfiguration). Do you think it's an important scenario for some reason? As you hint, if the mobile node has a DNS name for itself which is stable, then perhaps the DNS can provide the bootstrap. (If the mobile node doesn't have a home DNS name, then what functionality is Mobile IPv6 supposed to provide in this situation?) More generally, the Mobile IPv6 spec doesn't solve the mobile node configuration problem. Rich From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Feb 6 00:25:07 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA25861 for ; Tue, 6 Feb 2001 00:25:07 -0500 (EST) Received: from standards (47.234.32.16:1639) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD4292@standards.nortelnetworks.com>; Tue, 6 Feb 2001 0:02:33 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39840 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Feb 2001 00:02:32 -0500 Received: from ms.hansol.co.kr (210.112.2.207:2076) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD4290@standards.nortelnetworks.com>; Tue, 6 Feb 2001 0:02:31 -0500 Received: from ns ([211.113.87.7]) by ms.hansol.co.kr (8.9.3/8.9.3) with SMTP id OAA30583; Tue, 6 Feb 2001 14:19:01 +0900 References: <006301c08f13$cd0ce9a0$d012060a@hansol.co.kr> <3A7E89E2.57F80748@inrialpes.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Approved-By: Jiwoong Lee Message-ID: <016001c08ffd$0265d5a0$d012060a@hansol.co.kr> Date: Tue, 6 Feb 2001 14:23:28 +0900 Reply-To: Jiwoong Lee Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jiwoong Lee Subject: Re: [MOBILE-IP] IPv6 Mobile Router again, for Multicast X-To: Thierry Ernst To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id AAA25861 Thank you Thierry, I've read through your ID about IPv6 Mobile Router/Network. I'm thinking of Dynamic Prefix Assignment and Prefix Binding Update for IPv6 Mobile Network. I believe it will help to soothe some technical problems including multi-homing mobile networks, and multi-level mobile networks, flexible mobility of mobile nodes in a mobile network. By the way I have to confess I've not been seriously immersing myself in this topic as you have. Rather, I'd like to know the current intention of the authors of Mobile IPv6, in regard to my first question. Jiwoong ----- Original Message ----- From: Thierry Ernst To: Cc: Jiwoong Lee Sent: Monday, February 05, 2001 8:09 PM Subject: Re: [MOBILE-IP] IPv6 Mobile Router again, for Multicast > Hi Jiwoong, > > I cannot reply about Multicast. > > What is sure is that if there are some hosts connected to your Mobile > Router, they will never get any unicast packet. > > A mobile router basically means a mobile network or mobile subnetwork > since a Router is usually serving a set of hosts. All the set is > therefore moving together. Only the Mobile Router ITSELF can receive > packets, not the other nodes in the mobile network. The reasons are > better explained in my draft that you could find on the IETF web site > http://search.ietf.org/internet-drafts/draft-ernst-mobileip-v6-network-01.txt > (or alternatively on my web page together with my presentation made at > last IETF). > > I would be happy to hear any comment from you concerning the multicast > issues. > > Hope this helps, > Thierry. > > > Jiwoong Lee wrote: > > > > Note: This is the thirdly repeated message for ML server's erroneous processing. > > > > I've browsed the previous discussion in this ML for IPv6 mobile router. Before resolving the unicast problem, MobileIPv6 ID-ver13 seems to block any possibility to support a IPv6 mobile multicast router. I'm not clear enough about this. Anyone can give me some background explanation? > > > > Jiwoong. > > > > Please refer: > > > > Multicast packets addressed to a multicast address with link-local scope [9], to which the mobile node is subscribed, MUST NOT be tunneled to the mobile node; such packets SHOULD be silently discarded (after delivering to other local multicast recipients). (pp.68) From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Feb 6 04:50:18 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10417 for ; Tue, 6 Feb 2001 04:50:18 -0500 (EST) Received: from standards (47.234.32.16:3627) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD4411@standards.nortelnetworks.com>; Tue, 6 Feb 2001 4:27:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 40342 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Feb 2001 04:27:42 -0500 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD440F@standards.nortelnetworks.com>; Tue, 6 Feb 2001 4:27:42 -0500 Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f169mQd29716; Tue, 6 Feb 2001 10:48:27 +0100 (MET) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id KAA08084; Tue, 6 Feb 2001 10:48:26 +0100 X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en, sv MIME-Version: 1.0 References: <034BEFD03799D411A59F00508BDF75465B6979@esealnt448.al.sw.ericsson.se> <3A7F3365.9DBB43A6@Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Mattias Pettersson Message-ID: <3A7FC35D.B3568780@era.ericsson.se> Date: Tue, 6 Feb 2001 10:26:53 +0100 Reply-To: Mattias Pettersson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Mattias Pettersson Organization: Ericsson Radio Systems AB Subject: Re: [MOBILE-IP] IPv6 Prefix Deprecation Problem X-To: "T.J. Kniveton" X-cc: ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit "T.J. Kniveton" wrote: > > Mattias Pettersson wrote: > > Are your prefix lifetimes not supposed to be in the same order as the > > renumbering period? If your renumbering takes one month, set valid > > lifetime to one month for prefixes announces long before the renumbering > > phase starts. In this way you won't end up in situations like this. > > It may or may not be possible to have enough a priori knowledge of the > renumbering to start advertising shortened lifetimes "long" before the > renumbering. Regardless, wouldn't it be better to have a spec that > handles possible and reasonable situations, rather than saying things > will work if you implement and configure just-so? Along with what Richard Draves I think that the site administrator has to plan things already when the site is constructed. Also, since ND is un-acknowledged when it comes to RAs, this can happen: - The router sends RAs with lifetime of one year. - A host configures itself with this. - The router decreases RA lifetime to one week. - The host misses all RAs from this point. - After one week the old prefix is invalid on the link. - The host still sees it valid for almost one year unless it's being advertised with lifetime 0. Unlikely, but still possible. So the initial lifetime of one year is a bad choice. > > To me, it is not a far stretch of the imagination to picture a laptop > that is a MN running MIPv6, which sits for a long period of time on a > foreign network, and is switched off for a few months. I mean, maybe > it's not the common case..but it should still work! Right? I agree with you to 100% that it should work. The MN should not be useless after such an event. > > > Next, I wouldn't be sure that a Mobile Node would remember it's home > > prefix lifetime if it was switched off. > > OK.. But if the state this machine is keeping around is its home network > prefix, it could be toast. If it is keeping its home address, home agent > address, and home network prefix without any lifetimes, it still may not > be able to communicate with its home network or any correspondents using > its home address. The lifetime is not really the problem. It's how much > information and support you need to determine your identity and origins. Sure, please see below. > > > One requirement that we came up to when writing Mobile IPv6 i-d v13 was > > that the Mobile Node must somehow know its home prefix or a DNS name > > representing the home prefix or home agents anycast address. How the > > Well, DNS is the option that's most likely to survive a network > renumbering. But, can we really mandate that DNS is available for a > mobile node when it's configuring on a foreign network?... > > > Mobile Node learns this is out of scope of the draft. Thus, the upper > > Appendix A deals with it in a limited situation as Hesham denoted above. > What if DNS is not available? It may also be able to continue supporting > mobility at the IP layer, but without use of the Home Address, if the > home network can not be resolved. I.e. what if the visited network > becomes your new, temporary "home network" and you can continue to roam, > keeping open TCP connections, using your COA as your "home address". Nobody can contact you, since they don't know your new home address. Does the foreign network want to give you this service? > > Is there any interest in exploring the issue (beyond the scope of the > draft, if need be)? > > > layer that provides the Mobile Node with the home prefix in the first > > place, must also provide the new renumbered home prefix in cases like > > this when the Mobile Node is switched off during renumbering. > > Good point. > I think we should not put any futher requirements on Mobile IPv6 itself. The bootstrapping sequence described in Appendix A takes care of everything, with one requirement: Mobile IPv6 needs the home prefix. Some function has to find out this current home prefix on every invocation of Mobile IPv6. Example: while (1) { if (stored_home_prefix == NULL) { stored_home_prefix = magic_function(magic_ID); } error = invoke_mobile_ipv6(stored_home_prefix); if (error) { stored_home_prefix = NULL; } } So Mobile IPv6 would complain if stored_home_prefix wouldn't work and thus need to fall back on some other (magic) function, e.g. - function = DNS, ID = home agents anycast address name, for instance - function = AAA, ID = NAI (?) - function = manual... user has to find the new home prefix. - ... Whatever this function is it is needed when we create a system using Mobile IPv6. However, Mobile IPv6 itself doesn't need this. If the foreign network doesn't support AAA or DNS, maybe we have to stick to manual intervention. Or do we want to agree upon a new method, in addition to the ones listed above? The problem is to make every foreign network support them. /Mattias From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Feb 6 11:49:49 2001 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21958 for ; Tue, 6 Feb 2001 11:49:47 -0500 (EST) Received: from standards (47.234.32.16:4041) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD4748@standards.nortelnetworks.com>; Tue, 6 Feb 2001 11:26:38 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41434 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Feb 2001 11:26:38 -0500 Received: from RRMAIL01.RADIOROUTER_NT (63.103.94.23:2190) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBD4746@standards.nortelnetworks.com>; Tue, 6 Feb 2001 11:26:37 -0500 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id <1M1X1TMT>; Tue, 6 Feb 2001 11:47:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Approved-By: George Tsirtsis Message-ID: Date: Tue, 6 Feb 2001 11:47:20 -0500 Reply-To: George Tsirtsis Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: George Tsirtsis Subject: [MOBILE-IP] Fast Handovers for MIPv6 - new Draft To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM All, This was sent to the I-D directory today and should come out in a a couple of days...in the mean time here is a sneak preview. This version is much improved over v00 and a lot different although the basic ideas are the same. It is just more compact and with fewer options. Suggestions and improvements are always very welcome. Comments and 'polite' flames :) on the mailing list or to any of the co-authors if not of general interest. Best Regards George (for the design team) ---------------------------cut here---------------------------------- Personal G. Tsirtsis Editor A. Yegin C. Perkins G. Dommety K. El-Malki M. Khalil Internet Draft Title: draft-designteam-fast-mipv6-01.txt Category: Informational February 2001 Expires : July 2001 Fast Handovers for Mobile IPv6 Status of This Memo This document is a submission by the mobile-ip Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract This document specifies protocol enhancements to MIPv6 that enable mobile nodes to more quickly become connected at new points of attachment to the Internet. These protocol enhancements are intended to minimize the time during which the mobile node is unable to send or receive IPv6 packets (i.e., the handover latency). Design Team 1 Internet Draft Fast Handovers for MIPv6 February 2001 1. Introduction This draft presents the initial output of the MIPv6 Design Team on Fast Handovers with Mobile IPv6. The design decision has been taken not to consider scenarios in which the handover cannot be initiated until the mobile node has layer-2 connectivity to the new access router, since these are covered adequately by the base Mobile IPv6 Specification [MIPv6]. In scenarios which the handover can be initiated while the mobile node still has layer-2 connectivity at the previous access router, another design decision has been taken. Since this specification deals with layer-3 issues, the handover is considered to require some layer three information relevant to the new access router. Specifically, the handover at layer 3 requires a new care-of address on the new link, as well as prefix lifetime information and possibly other link parameters typically advertised by the new access router. In parallel the acquisition of this new care-of address should be performed in away that a duplicate or invalid address can not be picked and in the rear case that it does the system to be able to recover gracefully. Situations where the mobile node would be expected to acquire this information from advertisements from the new access router while still maintaining layer-2 connectivity with the previous access router are excluded from consideration in this specification. Otherwise, the protocol would actually become a special case of again the base MIPv6 specification. 2. Protocol Overview The aim of this protocol is to enable the MN to configure a newCOA before it moves to a newAR in a way that can use this newCOA immediately at connection with newAR. The areas of preparation are newCOA configuration, Duplicate Addressing avoidance and Neighbor Discovery. The pictured model provides standard terminology, standard behavior, standard messages, and standard message semantics that enable fast handover behavior with minimal interruption to packets flowing to a mobile node as it moves. This model applies both to networks in which the network determines that a handover will take place and to networks in which the mobile determines that a handover will take place. The model also preserves the Mobile IP characteristic of having the mobile making the ultimate determination of whether traffic destined to it is diverted to its new point of attachment. Design Team 2 Internet Draft Fast Handovers for MIPv6 February 2001 MN oldAR newAR | | | |-----RtSolPr-------->| | | | | |<------PrRtAdv-------| | | |--------HI--------->| |----------BU-------->| | |<---------BACK-------|<-------HACK--------| | forward | | packets===============>| | | | |--------------------NA-----------> | | | deliver |<=====================================Packets Figure 1: General Framework. Fast handover is implemented by adding 4 new messages which are implemented between access routers and between an access router and a mobile node. An access router is the last router between the network and the mobile node. From the point of view of an upcoming handover, the old Access Router (oldAR) is the router to which the mobile node is currently attached (mobile's default router) and the new Access Router (newAR) is the router to which the mobile node is about to move. The following messages are used in this specification and are defined in detail in later sections: - Router Solicitation for Proxy (RtSolPr) - MN to oldAR - Proxy Router Advert (PrRtAdv) - oldAR to MN - Handover Initiate (HI) - oldAR to newAR - Handover Ack (HAck) - newAR to oldAR - Binding Update (BU/BACK) - as defined in [MIPv6] + some flags The behavior of the entities involved in the exchange are described as follows. To initiate a fast handover the mobile node sends a Router Solicitation for Proxy to the oldAR indicating that it desires to implement a fast handover to a new attachment point. The Router Solicitation Proxy contains some form of identifier to indicate the new attachment point. It will receive in response a Proxy Router Advertisement message from the oldAR with a set of possible responses indicating that the point of attachment is unknown, the point of attachment is known and is connected through the same access router, or is known and here is the prefix (or care-of-address) you should Design Team 3 Internet Draft Fast Handovers for MIPv6 February 2001 use to form your new care-of-address (COA). The mobile node sends a Binding Update using its newly formed COA as the last message before it executes the handover. The mobile node then receives a Binding Acknowledgement either through the oldAR or the newAR indicating that the binding was complete. Whenever a mobile node moves to the newAR it sends the Neighbor Advertisement to initiate the flow of packets that may be waiting there for the mobile. The oldAR can also initiate a handover for the mobile node using the same messages. In this case the mobile node receives a Proxy Router Advertisement with a new prefix (or care-of-address) indicating that the mobile is about to be moved. The mobile responds by sending a Binding Update to the oldAR with its new care-of-address. The mobile receives a Binding Acknowledgement indicating that the handover is complete. The MN needs to be prepared for a number of error conditions. It may not receive a response to an initial RtSolPr in which case it needs to resend it. It also may not receive a response to its Binding Update in which case it needs to sends a Neighbor Advertisement to the newAR. If it does not receive its BACK at this point, the Binding Update never got to the old access router and the Binding Update needs to be resent. The oldAR communicates with the MN using the exchange of packets described above. If the mobile node is initiating the handover it will receive a Router Solicitation Proxy with some access network information. It will respond to this in one of three ways. If it does not understand the access network information it will respond saying that the access network information is unknown. If the oldAR understands the access network information but realizes that the access network information provided uses the same access router it will respond that the mobile node will continue to use the same access router. If the oldAR recognizes the access network information but realizes it uses a different access router, it will respond with a care-of-address or prefix for the new Access Router. The oldAR MUST wait for a Binding Update from the MN before actually forwarding packets. The oldAR sends a Binding Update acknowledgement message to the mobile node through the temporary tunnel that is constructed and to the mobile node over its old link. If the oldAR is initiating the handover, it will begin the exchange by using the Proxy Router Advertisement informing the MN of the new care-of-address that will be used to deliver packets to it. The oldAR MUST wait for a Binding Update from the MN before actually forwarding packets. The oldAR sends a Binding Acknowledgement message to the mobile node through the temporary tunnel that is constructed and to the mobile node over its old link. In addition to the exchange with the MN the oldAR exchanges information with the newAR to facilitate the forwarding of packets between the two and reduce the latency perceived by the MN during the handover. The oldAR sends a Handover Initiate (HI) message to the Design Team 4 Internet Draft Fast Handovers for MIPv6 February 2001 newAR with the requested care-of-address on the newAR and the care- of-address being used currently at the oldAR. The oldAR receives in response a Handover Acknowledgement (HACK) message either accepting or rejecting the new care-of-address. If the new care-of-address is accepted, the oldAR sets up a temporary tunnel to forward packets destined for the mobile to the new care-of-address on the newAR. If the new care-of-address is rejected by the newAR, the oldAR sets up a temporary tunnel to forward packets destined for the mobile to the old care-of-address which will be temporarily hosted on the newAR. In either case the oldAR does not forward packets until it has received a Binding Update from the MN. In the case of stateful address allocation, the HI/HACK exchange needs to be completed before the Proxy Router Advertisement is sent to the mobile node. The newAR also exchanges messages with the oldAR and forwards messages between the oldAR and the MN. When the newAR receives an HI message without a new COA it allocates a new COA and sends it to the oldAR in the HACK message. When the newAR receives an HI message with a new COA it determines whether the newCOA is valid and sends an indication in the HACK message. If a valid newCOA is returned to the oldAR the newAR will be receiving packets for the MN with a valid newCOA and will just forward them as normal to the MN. If no valid newCOA is determined, the newAR will record the oldCOA, de-tunnel the packets received in the tunnel from the oldAR and deliver them to the MN. The newAR will deliver packets to the MN when it receives an indication from the access network that it can begin sending packets to the MN or when it receives a neighbor advertisement from the MN, also an indication that it can send packets to the MN. The following summarizes the semantics of the messages. The Router Solicitation for Proxy is always an indication to the oldAR that the MN would like to perform a handover and is requesting information to enable the handover to be performed with minimal interruption. The Proxy Router Advertisement is an indication that the MN should go ahead and move and it provides the prefix or address to be used on the New AR. If the handover is mobile determined it provides information about whether the handover will involve moving to a new AR. If the handover is network determined it provides the indication that the mobile is about to be moved and the information that it will be using in the newAR. In network determined handover, failure to conform with the Proxy Router Advertisement may result in loss of service. The Binding Update indicates the Binding that the mobile node wants the oldAR to make. It also indicates to the network that the mobile is moving and that it wants its packets forwarded. Design Team 5 Internet Draft Fast Handovers for MIPv6 February 2001 The Binding Update Ack indicates whether the Binding Update was successful. A negative acknowledgement may indicate that the newCOA is invalid or that the Binding Update failed for any of the standard reasons. The Handover Initiate Message indicates the oldAR is trying to facilitate a fast handover to the newAR and the oldCOA that will be used in the case that the requested address negotiation between the routers fail. The Handover Ack Message indicates what the newCOA should be in the new Router. 3. Supported scenarios The framework described above applies to two main network scenarios. A Network Determined Handover scenario were the network is responsible for moving the mobile node from one attachment point to another and a Mobile Determined Handover scenario were the mobile itself has to define and initiate the handovers. In either case the ultimate decision is on the mobile, in that no routing change (no redirection of packets) takes place unless the MN confirms the handover with a Binding Update to the old Access Router. 3.1. Network Determined Handover In this scenario both stateless and stateful care of address configuration is supported. 3.1.1. Stateless new Care-of-Address Configuration When the oldAR realizes (or gets notified) that a MN must move to a newAR it compiles a newCOA based on the MN's Interface ID and the newAR's Prefix. It then sends this newCOA to the MN together with the NewAR IP address and Link Layer Address using the PrRtAdv message. At the same time the oldAR sends the HI message to the newAR indicating the MN's oldCOA as well as the newly created newCOA. The newAR first establishes whether the newCOA is a valid address performing checks to ensure that it is not a duplicate. If the newCOA is legal and acceptable to the newAR it adds it to the Neighboring Cash for a short time period so it can defend it and it responds with an HACK. If the newCOA is not valid (e.g.: used by other node) the newAR adds a host route for the oldCOA pointing to its mobility interface, for a short time period and responds to the oldAR with a HACK (newCOA not valid). Design Team 6 Internet Draft Fast Handovers for MIPv6 February 2001 MN oldAR newAR | | | |<------PrRtAdv-------|--------HI--------->| |--------BU---------->|<-------HAck--------| Disconnect <--BACK--|--BACK--> | | | | | forward | | packets===============>| | | | |--------------------NA-----------> | | | deliver |<=====================================Packets Figure 2: Network Determined and Stateless If the HACK indicates the newCOA is valid the oldAR will get ready to forward packets for this MN to its newCOA. If the HACK indicates the newCOA is not valid the oldAR will get ready to forward packets for this MN to the newAR. The oldAR will only change its routing regarding an MN after it receives a BU from the MN confirming the handover. This BU SHOULD be sent (if permitted by the link layer conditions at handover time) to the oldAR while the MN is still connected to the oldAR. If this is not possible the BU MUST be sent after the MN connects to the newAR. The oldAR MUST then send a BACK message to the MN both locally and by way of newAR (using the newCOA or the newAR as encapsulating address) On reception of the BU and providing the HACK has also been received, the oldAR can start forwarding packets destined to the MN's oCOA to either the newCOA or the newAR, depending of the HACK value. Now the oldAR acts as a Home Agent with home address being the MN's oldCOA and care-of-address being either the MN's newCOA or the newAR address. The MN MUST NOT use the newCOA address as source address until it receives a BACK from the oldAR. The BACK may be received while the MN is still connected to the oldAR in which case the MN will only have to announce itself to the newAR to get full connectivity. In the case were the BACK was sent but not received at the oldAR, there will be a copy of it waiting for the MN at the newAR. If the BACK is not received at all the MN should assume the BU was not received by the oldAR and it MUST resent the BU to the oldAR. 3.1.2. Stateful new Care-of-Address Configuration Design Team 7 Internet Draft Fast Handovers for MIPv6 February 2001 An alternative message sequence has HI/HAck message exchange proceeds the PrRtAdv message send from the oldAR to the MN. This provides a way to retrieve the correct contents for the PrRtAdv from the newAR when this information is not available to the oldAR by other means. MN oldAR newAR | | | | |--------HI--------->| | |<-------HAck--------| |<------PrRtAdv-------| | | | | Figure 3: Network Determined and Stateful The rest of the process is identical to the stateless approach 3.2. Mobile Determined Handover The main difference between this and the Network Determined approach is that here the mobile node MUST send a Router Solicitation for Proxy message to the oldAR and trigger the Proxy router Advertisement. In the RtSolPr message the MN indicates the Link Layer address or the Identifier of the Attachment Point that it wants to attach to. The oldAR will then reply with a PrRtAdv which contains the same information with the stateless approach of Network Determined approach. MN oldAR newAR | | | |------RtSolPr------->| | |<-----PrRtAdv--------|--------HI--------->| |--------BU---------->|<------HACK---------| Disconnect <--BACK--|--BACK--> | | | | | forward | | packets===============>| Connect | | |------------------NA-------------> | | | Deliver |<=====================================Packets Figure 4: Mobile Determined Design Team 8 Internet Draft Fast Handovers for MIPv6 February 2001 The rest of the behavior is the same in that the newCOA is sent to the newAR for validation using the HI/HACK sequence and the oldAR does not changes its routing regarding the mobile in question unless it receives a Binding Update from it, while the MN does not use the newCOA until it receives a BACK. After all this is done, as before, the oldAR acts as a Home Agent with home address being the MN's oldCOA and care-of-address being either the MN's newCOA or the newAR address. 3.3. Sending Binding Updates at the New Access Router When the mobile node move to a new access router, it needs to send a Binding Update to its home agent. It also may need to send a Binding Update to its old access router, unless it has a positive indication that the old access router already has made the appropriate binding cache modifications. The typical form of such a positive indication is a Binding Acknowledgement send from the old access router to the mobile node; if the mobile node expects but does not receive the acknowledgement, then it must effectively carry out the retransmission algorithm for Binding Updates, as specified in [MIPv6]. In this section, it is considered that all necessary link establishment details have been completed. This may possibly include Duplicate Address Detection, and/or reception of a Router Advertisement from the new access router. Those events may not always have to occur, and when they are needed they must have occurred before the transmission of Binding Updates messages. When the new access router receives any packet from the mobile node to be forwarded elsewhere, it means that the mobile node considers the new access router to be its default router, and thus that link establishment is complete from the point of view of the mobile node. If the Binding Acknowledgement was received, then the mobile node only has to send the Binding Update to its home agent. In that case, that Binding Update would be sent through the mobile node's default router--that is, the new access router. If on the other hand the mobile node has not yet received a Binding Acknowledgement from the old access router, then the mobile node SHOULD arrange for oldAR to receive an appropriate Binding Update associating the mobile node's new care-of address to its new care-of address (as specified in [MIPv6]). Therefore, we specify that if the mobile node knows the address of the newAR, it should first send any necessary Binding Update packet to its old access router, before sending the Binding Update packet to its home agent. Furthermore, alternative encapsulation strategies, which would allow both Binding Update options to be sent with a single transmission over the air from the mobile node, are the subject of current discussion in the design team. Design Team 9 Internet Draft Fast Handovers for MIPv6 February 2001 If the mobile node does not know the address of the new access router, Neighbor Discovery will have to take place before the Binding Update is send. In some circumstances, packets sent by the mobile node to the previous access router just before handover may have been dropped. If this information contained directives to the oldAR to initiate the smooth handover, the new access router may not have taken any steps to speed up the handover before the mobile node arrives. In this case, the mobile node may assume that the new access router is ready to provide connectivity, and then send a Binding Update through the new access router before Duplicate Address Detection has been accomplished for the new care-of address. In this case, the new access router is expected to send a (perhaps newly defined) ICMP message back to the mobile node. After taking care of the necessary processes to protect its link-local address on the network at the new point of attachment, the mobile node MAY resend the same Binding Update packet(s) to the new access router, and/or home agent without any recalculation. 3.3.1. Features enabling Partial Handover Optimization The following features are related, and yet able to be separated, and enable various facets of connectivity between the mobile node and the new access router. 1. The mobile node may be able to discover the IP address of the new access router 2. The mobile node may be able to discover the MAC address of the new access router. 3. The mobile node may be able to direct the new access router to ascertain the uniqueness of its new care-of address before establishing connectivity with the new access router 4. The mobile node may be able to send a Binding Update to its previous access router before breaking the previous connection 4a. The mobile node may be able to receive the Binding Acknowledgement for the Binding Update sent to the old access router before breaking the old connection. 4b. The mobile node may fail to receive the Binding Acknowledgement for the Binding Update sent to the previous access router before breaking the old connection. All of these operations are possibly both in the network-determined and the mobile-determined scenarios. Design Team 10 Internet Draft Fast Handovers for MIPv6 February 2001 If (1), (2), and (3) hold, then the mobile node can begin to use the new access router as its default router as soon as layer-2 connectivity is established. Thus, in this optimal circumstance, any necessary Binding Updates can be delivered without any additional delay as soon as the mobile node gets to the new network. If any of (1), (2) or (3) do not hold, then the mobile node is required to perform some combination of Neighbor Discovery and Duplicate Address Detection when it arrives at the new access router's area. For all of cases 4, 4a, 4b, a simple rule is effective. If the mobile node does not receive a Binding Acknowledgement for the Binding Updates that it has sent, then it MUST retransmit those Binding Updates according to the retransmission algorithm specified in the base Mobile IPv6 document. 4. Message Extension and Option Formats In this section, message and option formats are specified. The description for each message extension and option will specify which message or option it may be used with. 4.1. Router Solicitation for Proxy (RtSolPr) Hosts send Router Solicitation for Proxy in order to prompt routers for Proxy Router Advertisements. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address An IP address assigned to the sending interface Destination Address The address of the Access Router Hop Limit 255 Design Team 11 Internet Draft Fast Handovers for MIPv6 February 2001 Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header. ICMP Fields: Type TBA Code 0 Checksum The ICMP checksum. See [ICMPv6]. Identifier MUST be set by the sender so replies can be matched to this Solicitation. Reserved MUST be set to zero by the sender and ignored by the receiver. Valid Options: Source link-layer address The link-layer address of the sender, if known. It SHOULD be included on link layers that have addresses. New attachment point link-layer address The link-layer address or identification of the attachment point the mobile node requests routing advertisement information for. It MUST be included in all RtSolPr messages. Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message. Description The mobile node MUST sends this message if it wants to initiate a fast handover. It indicates its destination with the New Attachment Point Link-Layer Address. A PrRtAdv message should be received in response. If such message is not received in a short time period but no less than 2 times the typical round trip time (RTT) over the access link or 100msec if RTT is not known, it SHOULD resend it once or at the most twice (after the same waiting time). If the PrRtAdv is not received by the time the mobile node disconnects from oldAR, Fast Handover can not be performed and the mobile node SHOULD revert back to normal MIPv6. Design Team 12 Internet Draft Fast Handovers for MIPv6 February 2001 4.2 Proxy Router Advertisement (PrRtAdv) Routers send out Router Advertisement message unsolicited if the network is controlling the handover or in response to a Router Solicitation for Proxy message from a mobile node. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address MUST be the link-local address assigned to the interface from which this message is sent. Destination Address The Source Address of an invoking Router Solicitation for Proxy or the address of the node the Access Router is instructing to handover. Hop Limit 255 Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header. ICMP Fields: Type TBA Code 0 - Handover Information 1 - No change of COA required 2 - New Attachment Point not known Checksum The ICMP checksum. See [ICMPv6]. Identifier Copied from Router Solicitation for Proxy or set to Zero if unsolicited. Design Team 13 Internet Draft Fast Handovers for MIPv6 February 2001 Reserved MUST be set to zero by the sender and ignored by the receiver. Valid Options: Source link-layer address The link-layer address of the sender, if known. It SHOULD be included on link layers that have addresses. Link-layer address of proxied originator The link-layer address of the Access Router for which this message is proxied for. Prefix Information These options specify the prefixes of the Access Router the message is proxied for and are used for address autoconfiguration. New COA Option In sateful configuration, this option MUST be sent to allocate an address on behalf of the Access Router this message is proxied for. In stateless address auto-configuration this option may or may not be sent. If sent, indicates that the requesting node SHOULD use this address as newCOA for the duration of the handover. If not sent the requesting node SHOULD compute the newCOA using the Interface ID from the Destination Address of this message. Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message. Description A PrRtAdv with Code 0 but without a New COA Option means that the mobile node SHOULD construct a newCOA out of its Interface ID (used in the Destination Address in this PrRtAdv) and the Prefix in the Prefix Information Option. A PrRtAdv with Code 0 and a New COA Option means that the mobile node SHOULD use the COA indicated as a newCOA at the new Access Router. This MUST used when Stateful COA configuration is in use and MAY be used to help the oldAR and MN calculate the same newCOA when Stateless COA configuration is used. A PrRtAdv with Code 1 is sent if handover to the New Attachment Point, as indicated by the New Attachment Point Link Layer address in the corresponding RtSolPr message, Design Team 14 Internet Draft Fast Handovers for MIPv6 February 2001 does not require change of COA. No options required in this case. A PrRtAdv with Code 2 means that the oldAR is not aware of the Prefix Information requested. The MN MUST give up its attempt to perform fast handover to this new attachment point. Normal MIPv6 MAY be used instead. No options required in this case. This message is sent once for every RtSolPr received. 4.3. Handover Initiation (HI) The Handover Initiation message is a new ICMPv6 message sent by the old Access Router to new Access Router to initiate the process of Mobile Node's handover from one sub-network to another. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier |S|U| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address The IP address of the Router sending this message Destination Address The IP address of the Router this message is sent To. Hop Limit 255 Authentication Header A Security Association MUST exists between the sender and the destination address. This messages MUST be authenticated and so the authentication header MUST be used when this message is sent ICMP Fields: Type TBA Code 0 Checksum The ICMP checksum. See [ICMPv6]. Design Team 15 Internet Draft Fast Handovers for MIPv6 February 2001 Identifier MUST be set by the sender so replies can be matched to this Solicitation. S Stateful address configuration flag. When SET this message requests a new COA to be returned by the destination. U Buffer flag. The destination SHOULD buffer any packets towards the node indicated in the options of this message. Reserved MUST be set to zero by the sender and ignored by the receiver. Valid Options: Link-layer address of mobile node The link-layer address of the mobile node that is being handed of to the destination. This options SHOULD be included to help the destination recognize the mobile node when it will be connected to it. Old Care of Address The IP address used by the mobile node while attached to the originating router. This option MUST be included so packets to this mobile node can be redirected to the destination even if the new Care of Address is not acceptable. New Care of Address The IP address the mobile node wants to use when connected to the destination. In Stateless configuration this option indicates the new Care of Address the mobile node will be using when connected to the destination. Description If HACK message is not received as a response to this message. the HI SHOULD be resent up to 4 times using a short retransmission timer but no less than twice the round trip time between source and destination or 100msec if RTT is not known. Failure to receive an HACK means that no fast handover can be performed. The purpose of this message is to notify the newAR about the upcoming handover and establish a valid newCOA for the mobile node. If the S flag is SET this message requests an address from the newAR to be assigned statefully. If the new COA option is included the oldAR requests the newAR to confirm that this is a valid newCOA. Design Team 16 Internet Draft Fast Handovers for MIPv6 February 2001 4.4. Handover Acknowledgement (HACK) Message The Handover Acknowledgement message is a new ICMPv6 message that MUST be sent by the new Access Router to the old Access Router in response to a Handover Initiate message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address Copied from the destination address of the HI Message this message is in response to. Destination Address Copied from the source address of the HI Message this message is in response to. Hop Limit 255 Authentication Header A Security Association MUST exists between the sender and the destination address. This messages MUST be authenticated and so the authentication header MUST be used when this message is sent ICMP Fields: Type TBA Code 0-Handover Accepted, newCOA valid 1-Handover Accepted, newCOA not valid 2-Handover Accepted, newCOA in use 3-Handover Accepted, newCOA assigned (Stateful) 4-Handover Accepted, newCOA not assigned (Stateful) 128-Handover Not Accepted, reason unspecified 129-Administratively prohibited 130-Insufficient resources Design Team 17 Internet Draft Fast Handovers for MIPv6 February 2001 Checksum The ICMP checksum. See [ICMPv6]. Identifier Copied from the corresponding field in the HI message this message is in response to. Reserved MUST be set to zero by the sender and ignored by the receiver. Valid Options: New Care of Address If the S flag in the HI message is SET, this option Is used to provide the new Care of Address the mobile node should use when connected to this router. Description On reception of HI the newAR MUST respond with an HACK. If the S flag is SET in the HI, the newAR SHOULD include the new Care of Address option and a Code of 3. If the S flag is not SET in the HI, the newAR SHOULD check the validity of the newCOA sent with the HI and reply accordingly. If the newCOA is valid and the handover the newAR SHOULD insert the newCOA in its Neighbor Cash and defended on behalf of the mobile for a short period of time of a default value of 1 second in which period the mobile node is expected to connect to the newAR. If the newCOA is not valid or not assigned (Stateful) the newAR SHOULD insert a host route, pointing to its mobility interface the mobile node is expected to connect to, for the mobile's oldCOA. The newAR can always refuse the handover in which case it should indicate the reason in one of the available Code values. 4.5. IP Address Option This section defines the IP Address Option, used by the ICMPv6 messages defined in this document. The extension format is based on [MIER]. Design Team 18 Internet Draft Fast Handovers for MIPv6 February 2001 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Sub-Type | Length | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA Sub-Type 1 Old Care-of Address 2 New Care-of Address Length 3 Prefix Length The Length of the IPv6 Address Prefix IPv6 address The IP address for the unit defined by the Type field. This option is sent in the Proxy Router Advertisement, the Handover Initiate and Handover Acknowledgement messages. The PrRtAdv and HACK messages only contain the newCOA while the HI message may include both newCOA and oldCOA. 4.6. Link-layer Addresses (LLA) This extension is based on the [MIER] format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Sub-Type | Length | LLA ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Design Team 19 Internet Draft Fast Handovers for MIPv6 February 2001 Fields: Type TBA Sub-Type 1 for the Link-layer Address of the new Attachment Point. 2 for the Link-layer Address of the Mobile Node. 3 for the Link-layer Address of the Proxied Originator Length The length of the option (including the type, sub-type and length fields) in units of 8 octets. LLA The variable length link-layer address. The content and format of this field (including byte and bit ordering) is expected to be specified in specific documents that describe how IPv6 operates over different link layers. Description The New Attachment Point Link Layer address contains the link-layer address of the attachment point the mobile node attempts to handover to. This is used in the Router Solicitation for Proxy message. The Mobile Node Link-Layer address option contains the link- layer address of a mobile node. It is used in the Handover Initiation message. The Proxied Originator Link-Layer address option contains the Link Layer address of the Access Router the Proxy Router Solicitation message refers to. These options MUST be silently ignored for other Neighbor Discovery messages. NOTE: Source and Target Link Layer Addresses as defined in [ND] MAY also be used by Router Solicitation for Proxy and Proxy Routing Advertisement messages. 4.7 Modified Binding Update Option Two flags B, U are added to the flag bits in the Binding Update Option. The mobile node sets the B flag in the Binding Update, to indicate that the mobile node would like the AR to do bicasting. The mobile node sets the U flag in the Binding Update to indicate that the mobile node would like the AR to do buffering. Finally the AR MAY honor the bicasting and buffering requests or reject them silently. Design Team 20 Internet Draft Fast Handovers for MIPv6 February 2001 Thus, the Binding Update Option under Fast Handovers for Mobile IPv6 will show as below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|R|D|B|U|r|r| Prefix Length ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B The mobile node is requesting the AR to do bicasting. U The mobile node is requesting the AR to do buffering. r reserved and it MUST be set to 0. The rest of the flag bits and the other fields are as defined in [MIPv6]. Description This message MUST be send by the mobile node to the old Access Router so that the latter can redirect traffic to the mobile node by the way of the new Access Router. The message SHOULD be sent while the mobile node is still connected to the oldAR and a BACK SHOULD be received at the same place. If that is not possible, due to link layer conditions, the BU MUST be send or resend at the newAR and the BACK MUST be received before the mobile node can use the newCOA. The initial retransmission timer for the BU in this particular case should be very short but no less than 1.5 times theworst case RTT of the L2 after the MN connects to the newAR. The BU SHOULD be resent using exponential backoff but only once or at most twice more. If that does not yield a BACK the mobile node MUST give up the attempt for a fast handover and revert back to normal MIPv6. 5. Error Cases and other issues In this section we are going to examine some common error cases that may affect the performance and/or reliability of the mechanisms described in this specification. 5.1. DAD handling Design Team 21 Internet Draft Fast Handovers for MIPv6 February 2001 Duplicate Address Detection (DAD) was defined in [AUTO] to avoid address duplication on links when stateless address auto- configuration is used. The use of DAD to verify the uniqueness of a statelessly configured IPv6 address may add delays to a MIPv6 handover. The probability of an interface identifier duplication on the same subnet can be considered very low, however it can not be ignored. In this draft certain precautions are proposed to minimize the effects of a duplicate address occurrence. In some cases the new AR may already have the knowledge required to assess whether the MN's address is duplicated or not, before the MN moves to the new subnet. For example, the AR can have a list of all nodes on its subnet (may be used for access control) and by searching this list it can confirm whether the MN's address is duplicated. The result of this search can be sent back to the old AR in the HAck message. If such knowledge is not available in the new AR, the MN would have to perform DAD after moving to the new subnet. To avoid delays due to performing DAD, it is suggested that the MN performs DAD while using its oldCOA. This is possible since the framework described in this specification allows packet redirection based on the oldCOA encapsulated into the newAR IP address. So, if the newAR cannot confirm the validity of the newCOA address included in the HI message but is never the less willing to serve the MN it can describe that in the HACK message and install a host route towards its mobility interface regarding the MN's oldCOA. The oldAR on reception of this type of HACK replies with a BUNACK to the BU sent by the MN attempting to registers is newCOA. The oldAR now forwards packets for this MN to the newAR which will decapsulates and due to the host route installed earlier it can forward these packets to the mobile. The MN will at some point, either at the old or at the newAR receive the BUNACK and thus attempt to get a newCOA. If the MN does not receive the BACK or BUNACK at the oldAR and after connecting to the newAR it still does not receive it in a short time frame (X sec) it can assume that the BU was not received by the oldAR and it MUST retransmit it. The source address used in this BU SHOULD be the newCOA, which is not yet confirmed, to avoid ingress filtering. If the newCOA is not valid the oldAR will send (or resend) a BUNACK to the oldAR, encapsulated in the address of the newAR and thus it will safely be received by the MN. 6. Security Considerations The security needed for fast handover is almost the same as is needed for handling Binding Updates in IPv6. If a handover could Design Team 22 Internet Draft Fast Handovers for MIPv6 February 2001 be initiated by a node masquerading as the mobile node, a range of undesirable effects might result. The malicious node could usurp traffic destined from the mobile node, diverting it to a nearby router and possibly an unauthorized care-of address. The exact details of the possible effects would depend on the kinds of handover data available as part of the fast handover process. The Fast MIPv6 Handover proposal assumes that a security association exists between the oldAR and the MN, as well as between the old and newARs. Providing the above is true then, routing is only changes by a BU from the MN, which MUST be authenticated. It is also highly recommended that RtSolPr and PrRtAdv messages are also authenticated since they are between oldAR and MN which have a security association. 7. Acknowledgements Thanks to Basavaraj Patil and Phil Roberts for supporting this effort and the whole Mobile IP WG for participating in the initial discussion. References [ASSNUM] J. Reynolds, J. Postel, Assigned Numbers, Request For Comments (Standards Track) 1700. October 1994. [AUTO] S. Thomson and T. Narten. IPv6 Stateless Address Autoconfiguration. Request for Comments (Draft Standard) 2462, Internet Engineering Task Force, December 1998. [EUI] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997. [IMSI] TIA/EIA/IS-95-B [MAC] D. Plummer, "An Ethernet Address Resolution Protocol - or - Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", RFC 826, November 1982. [MIER] M.Khalil, R. Narayanan, H. Akhtar, E. Qaddoura, Mobile IP Extensions Rationalization (MIER)(work in progress). draft-ietf-mobileip-mier-05.txt, December 1999. [MIPv6] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in progress). draft-ietf-mobileip-ipv6-12.txt, April 2000. [ND] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461, Internet Engineering Task Force, December 1998. Design Team 23 Internet Draft Fast Handovers for MIPv6 February 2001 Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Motorola 6000 Connection Drive 1501 West Shure Drive M/S M8-540 Irving, Texas 75039 Arlington Heights, IL 60004 USA USA Phone: +1 972-894-6709 Phone: +1 847-632-3148 Fax : +1 972-894-5349 EMail: Basavaraj.Patil@nokia.com EMail: QA3445@email.mot.com The authors of this document are: Alper Yegin Sun Alper.Yegin@eng.sun.com Charles E. Perkins Nokia charliep@iprg.nokia.com George Tsirtsis Flarion G.Tsirtsis@flarion.com Gopal Dommety Cisco gdommety@cisco.com Karim El-Malki Ericsson Karim.El-Malki@era.ericsson.se Mohamed Khalil Nortel mkhalil@nortelnetworks.com Design Team 24 From ronyoung@nortelnetworks.com Thu Feb 8 17:23:47 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20892 for ; Thu, 8 Feb 2001 17:23:43 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Thu, 8 Feb 2001 12:53:02 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Thu, 8 Feb 2001 12:54:37 -0600 Received: from zrtps06t.us.nortel.com (zrtps06t.us.nortel.com [47.140.48.51]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id NAA11945 for ; Thu, 8 Feb 2001 13:40:52 -0500 (EST) Received: from ertpsms2.nortelnetworks.com (actually ertpsms2.internet.nortel.com) by zrtps06t; Thu, 8 Feb 2001 13:40:03 -0500 Received: from motgate2.mot.com ( [136.182.1.10]) by ertpsms2.nortelnetworks.com with SMTP (MailShield v1.5); Thu, 08 Feb 2001 13:41:28 -0500 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id LAA13482 for ; Thu, 8 Feb 2001 11:36:40 -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 LAA22299 for ; Thu, 8 Feb 2001 11:36:40 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2651.58) id <1LR91Z89>; Thu, 8 Feb 2001 12:36:40 -0600 Message-ID: From: Roberts Philip-qa3445 To: mobile-ip@marvin.corpeast.baynetworks.com Subject: Minneapolis Meeting Date: Thu, 8 Feb 2001 12:36:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain X-SMTP-HELO: motgate2.mot.com X-SMTP-MAIL-FROM: phil.roberts@motorola.com X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: [136.182.1.10] X-Orig: X-Orig: X-Orig: Hi folks, we're planning on one long slot for Mobile IP in Minneapolis with an agenda roughly as follows: Working Group Document Update Mobile IP v6 Update Fast Handoff Discussion for v4 Fast Handoff Discussion for v6 QoS considerations and Mobile IP Please send in requests for slots. If there are topics outside this list, please try to generate some discussion on them on the mailing list as well as making a request for a presentation slot. Phil From ronyoung@nortelnetworks.com Thu Feb 8 17:23:48 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20894 for ; Thu, 8 Feb 2001 17:23:43 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Thu, 8 Feb 2001 13:56:57 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Thu, 8 Feb 2001 13:57:34 -0600 Received: from zsc4s000.baynetworks.com (zsc4s000.baynetworks.com [134.177.3.63]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id OAA13100 for ; Thu, 8 Feb 2001 14:51:26 -0500 (EST) Received: from zsc4s004.corpwest.baynetworks.com (actually zsc4s004.baynetworks.com) by zsc4s000.baynetworks.com; Thu, 8 Feb 2001 11:50:02 -0800 Received: from fdpnmailgw5.dpn.deere.com ( [192.43.73.42]) by zsc4s004.corpwest.baynetworks.com with SMTP (MailShield v1.5); Thu, 08 Feb 2001 11:49:59 -0800 Received: from 192.43.73.42 by fdpnmailgw5.dpn.deere.com with SMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Wed, 07 Feb 2001 20:39:29 -0600 X-Server-Uuid: 2d3b7162-db1d-11d3-b8ee-0008c7dfb6f1 Received: from 192.9.25.1 by fdpnmailgw2.dpn.deere.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Mon, 05 Feb 2001 17:17:36 -0600 X-Server-Uuid: 2d3b7162-db1d-11d3-b8ee-0008c7dfb6f1 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA16435; Mon, 5 Feb 2001 15:17:15 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88] ) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA26953; Mon, 5 Feb 2001 15:16:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com ( 8.11.2+Sun/8.11.2) id f15NDu127129 for ipng-dist; Mon, 5 Feb 2001 15: 13:56 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f15NDh227122 for ; Mon, 5 Feb 2001 15:13:43 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA15733 for ; Mon, 5 Feb 2001 15:13:43 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06345 for ; Mon, 5 Feb 2001 16:13:42 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA13134; Mon, 5 Feb 2001 15:13:40 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com ( 8.11.0/8.11.0-DARKSTAR) id f15NDcF17844; Mon, 5 Feb 2001 15:13:38 -0800 X-Virus-Scanned: Mon, 5 Feb 2001 15:13:38 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Kniveton.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdBatH4b; Mon, 05 Feb 2001 15:13:34 PST Message-ID: <3A7F33A0.27D39D01@Kniveton.com> Date: Mon, 05 Feb 2001 15:13:36 -0800 From: "T.J. Kniveton" Organization: NOKIA Research X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com, mobile-ip@marvin.corpeast.baynetworks.com Subject: [Fwd: Re: IPv6 Prefix Deprecation Problem] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk X-WSS-ID: 169CD96B156619-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SMTP-HELO: fdpnmailgw5.dpn.deere.com X-SMTP-MAIL-FROM: TJ@Kniveton.com X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: [192.43.73.42] X-Orig: X-Orig: X-Orig: Content-Transfer-Encoding: 7bit "Hesham Soliman (ERA)" wrote: > => I don't have a concrete proposal but basically the problem > here is manual configuration of the Home address / prefix. > If the MN can decouple its identity from the Home prefix > and use something more abstract (eg. NAI) then the > problem can be solved. > - The MN starts in a foreign network > - It discovers its home address (By looking up the > NAI is some location management database. eg DNS) > - The MN does dynamic HA discovery > - The MN sends a BU to the HA. Thanks for your input, Hesham. This alternative, similar to Appendix A of the Draft, is one of the alternatives I was considering, and probably the best event sequence when DNS will help you out and you have configured with the NAI properly. There are a couple of other possibilities, and it might be optimal to have a fallback if you can not get the home network prefix because of lack of needed services, or lack of correct configuration. > In general manually configuring the Home address seems > to be a bad approach IMO. The above approach is implementation > dependant and would not require modifications to MIPv6. Yes, it probably takes the least amount of manual intervention, which is a good thing. Mattias Pettersson wrote: > Are your prefix lifetimes not supposed to be in the same order as the > renumbering period? If your renumbering takes one month, set valid > lifetime to one month for prefixes announces long before the renumbering > phase starts. In this way you won't end up in situations like this. It may or may not be possible to have enough a priori knowledge of the renumbering to start advertising shortened lifetimes "long" before the renumbering. Regardless, wouldn't it be better to have a spec that handles possible and reasonable situations, rather than saying things will work if you implement and configure just-so? To me, it is not a far stretch of the imagination to picture a laptop that is a MN running MIPv6, which sits for a long period of time on a foreign network, and is switched off for a few months. I mean, maybe it's not the common case..but it should still work! Right? > Next, I wouldn't be sure that a Mobile Node would remember it's home > prefix lifetime if it was switched off. OK.. But if the state this machine is keeping around is its home network prefix, it could be toast. If it is keeping its home address, home agent address, and home network prefix without any lifetimes, it still may not be able to communicate with its home network or any correspondents using its home address. The lifetime is not really the problem. It's how much information and support you need to determine your identity and origins. > One requirement that we came up to when writing Mobile IPv6 i-d v13 was > that the Mobile Node must somehow know its home prefix or a DNS name > representing the home prefix or home agents anycast address. How the Well, DNS is the option that's most likely to survive a network renumbering. But, can we really mandate that DNS is available for a mobile node when it's configuring on a foreign network?... > Mobile Node learns this is out of scope of the draft. Thus, the upper Appendix A deals with it in a limited situation as Hesham denoted above. What if DNS is not available? It may also be able to continue supporting mobility at the IP layer, but without use of the Home Address, if the home network can not be resolved. I.e. what if the visited network becomes your new, temporary "home network" and you can continue to roam, keeping open TCP connections, using your COA as your "home address". Is there any interest in exploring the issue (beyond the scope of the draft, if need be)? > layer that provides the Mobile Node with the home prefix in the first > place, must also provide the new renumbered home prefix in cases like > this when the Mobile Node is switched off during renumbering. Good point. -- T.J. Kniveton NOKIA Research Center -------------------------------------------------------------------- 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 ronyoung@nortelnetworks.com Thu Feb 8 17:39:42 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20893 for ; Thu, 8 Feb 2001 17:23:43 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Thu, 8 Feb 2001 14:25:30 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Thu, 8 Feb 2001 14:24:08 -0600 Received: from zsc4s000.baynetworks.com (zsc4s000.baynetworks.com [134.177.3.63]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id PAA13534 for ; Thu, 8 Feb 2001 15:18:27 -0500 (EST) Received: from zsc4s004.corpwest.baynetworks.com (actually zsc4s004.baynetworks.com) by zsc4s000.baynetworks.com; Thu, 8 Feb 2001 12:17:05 -0800 Received: from cisco.com (sigma.cisco.com [171.69.26.43]) by zsc4s004.corpwest.baynetworks.com with SMTP (MailShield v1.5); Thu, 08 Feb 2001 12:17:27 -0800 Received: from alpesh-u5.cisco.com (alpesh-u5.cisco.com [171.69.71.44]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id MAA01768; Thu, 8 Feb 2001 12:17:36 -0800 (PST) Message-Id: <200102082017.MAA01768@cisco.com> Date: Thu, 8 Feb 2001 12:17:36 -0800 (PST) From: Alpesh Patel Reply-To: Alpesh Patel Subject: question about agent advertisement in 2002.bis and rfc 2002 To: mobile-ip@marvin.corpeast.baynetworks.com Cc: Basavaraj.Patil@nokia.com, QA3445@email.mot.com, charliep@iprg.nokia.com, kleung@cisco.com, alpesh@sigma.cisco.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: kh2wrkjqtg8VQJmc1RWVrA== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc X-SMTP-HELO: cisco.com X-SMTP-MAIL-FROM: alpesh@sigma.cisco.com X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: sigma.cisco.com [171.69.26.43] X-Orig: X-Orig: X-Orig: Folks, The RFC and the .bis document states that the destination address in case of agent advertisement should be set to 224.0.0.1 (all systems on this link) or 255.255.255.255 (limited broadcast address). This is referred to RFC1256. There is no mention to setting the destination address in relation to an agent solicitation message. RFC1256 says that in response to an agent solicitation, the router should either unicast the response to the solicitating host's address or multicast it. No mention about using the limited broadcast address. The exact wording is attached: ******* In addition to the periodic, unsolicited advertisements, a router sends advertisements in response to valid solicitations received on any of its advertising interfaces. A router may choose to unicast Router Discovery Working Group [Page 10] ^L RFC 1256 ICMP Router Discovery Messages September 1991 the response directly to the soliciting host's address (if it is not zero), or multicast it to the interface's configured AdvertisementAddress; in the latter case, the interface's interval timer is reset to a new random value, as with unsolicited advertisements. ****** I would suggest to remove this comment about setting the destination to either the multicast or link specific broadcast to eliminate the confusion it is causing. Thanks -a From ronyoung@nortelnetworks.com Thu Feb 8 19:04:34 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21716 for ; Thu, 8 Feb 2001 19:04:34 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Thu, 8 Feb 2001 16:35:23 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Thu, 8 Feb 2001 16:40:12 -0600 Received: from zrchs148 (zrchs148.us.nortel.com [47.100.129.12]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id RAA15632 for ; Thu, 8 Feb 2001 17:32:51 -0500 (EST) Received: from zrchb200.us.nortel.com (actually zrchb200) by zrchs148; Thu, 8 Feb 2001 16:25:56 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1RT8ZY42>; Thu, 8 Feb 2001 16:32:49 -0600 Message-ID: From: "Ron Young" To: mobile-ip@marvin.corpeast.baynetworks.com Subject: Test Date: Thu, 8 Feb 2001 16:32:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0921F.0E468D00" X-Orig: X-Orig: ------_=_NextPart_001_01C0921F.0E468D00 Content-type: text/plain; charset="iso-8859-1" Test I'm just testing the mail server because it appears alot of people are not receiving mail. Test 2: from internal Nortel account ------------------------------------------------------------------------ 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_01C0921F.0E468D00 Content-type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Test

Test

I'm just testing the mail server because it appears = alot of people are not receiving mail. 

Test 2: from internal Nortel account

---------------------------------------------------------------= ---------
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_01C0921F.0E468D00-- From ronyoung@nortelnetworks.com Thu Feb 8 20:12:47 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22559 for ; Thu, 8 Feb 2001 20:12:47 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Thu, 8 Feb 2001 17:39:04 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Thu, 8 Feb 2001 17:41:50 -0600 Received: from zsc4s000.baynetworks.com (zsc4s000.baynetworks.com [134.177.3.63]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id SAA16553 for ; Thu, 8 Feb 2001 18:35:44 -0500 (EST) Received: from zsc4s004.corpwest.baynetworks.com (actually zsc4s004.baynetworks.com) by zsc4s000.baynetworks.com; Thu, 8 Feb 2001 15:34:13 -0800 Received: from web3302.mail.yahoo.com (web3302.mail.yahoo.com [204.71.201.25]) by zsc4s004.corpwest.baynetworks.com with SMTP (MailShield v1.5); Thu, 08 Feb 2001 15:34:45 -0800 Message-ID: <20010208233411.22167.qmail@web3302.mail.yahoo.com> Received: from [47.100.144.248] by web3302.mail.yahoo.com; Thu, 08 Feb 2001 15:34:11 PST Date: Thu, 8 Feb 2001 15:34:11 -0800 (PST) From: Ron Young Reply-To: ron.young@gte.net Subject: Test To: mobile-ip@marvin.corpeast.baynetworks.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SMTP-HELO: web3302.mail.yahoo.com X-SMTP-MAIL-FROM: moronnorom@yahoo.com X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: web3302.mail.yahoo.com [204.71.201.25] X-Orig: X-Orig: X-Orig: Test I'm just testing the mail server because it appears alot of people are not receiving mail. Test 1: from external account ===== Ron Young __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From ronyoung@nortelnetworks.com Thu Feb 8 23:27:52 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA26615 for ; Thu, 8 Feb 2001 23:27:52 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Thu, 8 Feb 2001 20:27:44 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Thu, 8 Feb 2001 20:27:43 -0600 Received: from zsc4s000.baynetworks.com (zsc4s000.baynetworks.com [134.177.3.63]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id VAA19052 for ; Thu, 8 Feb 2001 21:18:10 -0500 (EST) Received: from zsc4s004.corpwest.baynetworks.com (actually zsc4s004.baynetworks.com) by zsc4s000.baynetworks.com; Thu, 8 Feb 2001 18:16:51 -0800 Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by zsc4s004.corpwest.baynetworks.com with SMTP (MailShield v1.5); Thu, 08 Feb 2001 18:17:31 -0800 Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP id LAA17773; Fri, 9 Feb 2001 11:17:52 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id LAA18758; Fri, 9 Feb 2001 11:17:52 +0900 (JST) Received: from tanuki (tanuki.isl.rdc.toshiba.co.jp [133.196.16.162]) by isl.rdc.toshiba.co.jp (8.9.3/8.9.3/8.4) with SMTP id LAA10411; Fri, 9 Feb 2001 11:17:52 +0900 (JST) Message-Id: <200102090217.LAA10411@isl.rdc.toshiba.co.jp> Date: Fri, 09 Feb 2001 11:29:23 +0900 From: Yoshiyuki Tsuda Subject: Re: question about agent advertisement in 2002.bis and rfc 2002 To: Alpesh Patel Cc: mobile-ip@marvin.corpeast.baynetworks.com Organization: Corporate R&D Center, Toshiba Corporation In-Reply-To: <200102082017.MAA01768@cisco.com> References: <200102082017.MAA01768@cisco.com> X-Mailer: Datula version 1.50.45 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SMTP-HELO: tsbgw.wide.toshiba.co.jp X-SMTP-MAIL-FROM: tsuntsun@isl.rdc.toshiba.co.jp X-SMTP-RCPT-TO: mobile-ip@standards.nortelnetworks.com X-SMTP-PEER-INFO: tsbgw.wide.toshiba.co.jp [202.249.10.123] X-Orig: X-Orig: X-Orig: Hi Alpesh, Good suggestion. I prefer unicasting a solicited advertisement rather than unicasting or broadcasting. But, there is one pro and con about the sequence number in the Mobility agent advertisement extension(section 2.3.2). If Mobile Nodes miss an advertisement with the 0xFFFF sequence number, all Mobile Nodes will send registration requests at the next advertisement. Therefore, I more prefer: - unicasting a solicited advertisement in case of normal sequence number, - multicasting or broadcasting it in case of the 0xFFFF sequence number. Although I'm afraid it would become more complicated... Thanks. -Yoshi On Thu, 8 Feb 2001 12:17:36 -0800 (PST), Alpesh Patel wrote: >> Folks, >> >> The RFC and the .bis document states that the destination address in case >> of agent advertisement should be set to 224.0.0.1 (all systems on this >> link) or 255.255.255.255 (limited broadcast address). This is referred to >> RFC1256. There is no mention to setting the destination address in relation >> to an agent solicitation message. >> >> RFC1256 says that in response to an agent solicitation, the router should >> either unicast the response to the solicitating host's address or multicast >> it. No mention about using the limited broadcast address. The exact wording >> is attached: >> ******* >> In addition to the periodic, unsolicited advertisements, a router >> sends advertisements in response to valid solicitations received on >> any of its advertising interfaces. A router may choose to unicast >> >> Router Discovery Working Group [Page 10] >> ^L >> RFC 1256 ICMP Router Discovery Messages September 1991 >> >> the response directly to the soliciting host's address (if it is not >> zero), or multicast it to the interface's configured >> AdvertisementAddress; in the latter case, the interface's interval >> timer is reset to a new random value, as with unsolicited >> advertisements. >> ****** >> >> I would suggest to remove this comment about setting the destination to >> either the multicast or link specific broadcast to eliminate the confusion >> it is causing. >> >> Thanks >> -a From ronyoung@nortelnetworks.com Fri Feb 9 08:43:40 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16796 for ; Fri, 9 Feb 2001 08:43:40 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Fri, 9 Feb 2001 07:23:23 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Fri, 9 Feb 2001 07:23:33 -0600 Received: from qcarh006.nortelnetworks.com (zcars00w.ca.nortel.com [47.128.0.50]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id IAA19218 for ; Fri, 9 Feb 2001 08:14:08 -0500 (EST) Received: from ecarsaaa.nortelnetworks.com by qcarh006.nortelnetworks.com; Fri, 9 Feb 2001 08:11:51 -0500 Received: from RRMAIL01.RADIOROUTER_NT ( [63.103.94.23]) by ecarsaaa.nortelnetworks.com with SMTP (MailShield v1.5); Fri, 09 Feb 2001 08:13:24 -0500 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id <1M1X1VS1>; Fri, 9 Feb 2001 08:13:08 -0500 Message-ID: From: George Tsirtsis To: "'Erik Anderlind'" , MOBILE-IP@marvin.corpeast.baynetworks.com Subject: RE: Fast Handovers for MIPv6 - new Draft -comments BU+SA Date: Fri, 9 Feb 2001 08:13:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: RRMAIL01.RADIOROUTER_NT X-SMTP-MAIL-FROM: G.Tsirtsis@flarion.com X-SMTP-RCPT-TO: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM X-SMTP-PEER-INFO: [63.103.94.23] X-Orig: X-Orig: X-Orig: -----Original Message----- From: Erik Anderlind [mailto:eanderlind@lucent.com] Sent: Wednesday, February 07, 2001 10:36 PM To: George Tsirtsis; IP Routing for Wireless/Mobile Hosts (mobile-ip) Subject: Fast Handovers for MIPv6 - new Draft -comments BU+SA Hi George, Comment on Draft page 3: The mobile node sends a Binding Update using its newly formed COA as the last message before it executes the handover. The mobile node then receives a Binding Acknowledgement either through the oldAR or the newAR indicating that the binding was complete. Why allow the BU-ACK to be sent to either the old or the new address? I think the text should say: The BU-ACK is received on the COA used in the BU message. GT> That is correct but...the above statement only says that this message may be delivered *by way* of newAR or directly from the oldAR. We expect the oldAR to send it the BUACK both ways so we ensure that the message will be received by the mobile. Ideally we would like to deliver the BUACK to the MN before it moves but this can not be certain due to the degrading old link... Security considerations: THe assumption seems to be that the oldAR and newAR share the same security association, or the scheme is flawed. GT> Yes, the Fast Handover we describe can only be supported if there is an SA between old and newAR. We also assume an SA between MN and oldAR. There seems to be a need for establishing new direct SAa in the following scenario: Start: Mobile and AP_1 share an SA. GT> I assume that by AP you actually mean Access Routers...in which case yes. Step 1: Mobile initiates Handover to AP_2. (Draft states it is sufficient to have the following SAs: MS<->AP_1, AP_1<->AP_2) GT> Yes. Step 3: Mobile initiates handover from AP_2 to AP_3. THe draft does not require establishment of an SA betwen MS and AP_2, so there seems to be a transitive association {MS<->AP_1, AP_1<->AP_2, AP2<->AP_3} -> can verify MS <-> AP_3. The draft should state the mobile MUST negotiate an SA with AP_2 before it can perform a handoff to AP_3. GT> Yes, that is what we assume. SA between MN and AP_2 (or better AR_2) IS required but only when the MN handsoffs to AR_3...it is NOT, however, required for the MN to move from AR_1 to AR_2. George From ronyoung@nortelnetworks.com Fri Feb 9 10:47:00 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20685 for ; Fri, 9 Feb 2001 10:46:59 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Fri, 9 Feb 2001 09:32:24 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Fri, 9 Feb 2001 09:37:44 -0600 Received: from zrchs148 (zrchs148.us.nortel.com [47.100.129.12]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id KAA22400 for ; Fri, 9 Feb 2001 10:31:13 -0500 (EST) Received: from zrchb200.us.nortel.com (actually zrchb200) by zrchs148; Fri, 9 Feb 2001 09:24:18 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1RT85DGL>; Fri, 9 Feb 2001 09:31:11 -0600 Message-ID: From: "Ron Young" To: "'Jiwoong Lee'" Cc: mobile-ip@marvin.corpeast.baynetworks.com, "'phil.roberts@motorola.com'" , "'Basavaraj.Patil@nokia.com'" Subject: RE: Test Date: Fri, 9 Feb 2001 09:31:07 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C092AD.525F03D0" X-Orig: X-Orig: ------_=_NextPart_001_01C092AD.525F03D0 Content-type: text/plain; charset="iso-8859-1" Jiwoong, I apologize for not letting everyone know what was happening. I have no excuse except for being an idiot. Anyway, what is happening is that the owner of the mail server no longer has the resources to handle everything so the Mobile IP mailing list was moved to a different server and this server is running majordomo instead of listserv. From the end user perspective this should not change too much because the mail aliases have stayed the same. However, the problem we are seeing is some people are not getting the mail because their mail servers are returning the mail with "too many hops" errors. The problem should be fixed today. I will let everyone know when that happens. ------------------------------------------------------------------------ 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. -----Original Message----- From: Jiwoong Lee [mailto:porce@kaist.ac.kr] Sent: Thursday, February 08, 2001 10:57 PM To: Young, Ron [RICH1:IP21:EXCH] Subject: Re: Test Sir, Would you please explain what happend to this mobile IP ML if you are somewhat connected to this administration ? Thank you, (And posting to ML please.) ----- Original Message ----- From: Ron Young To: mobile-ip@marvin.corpeast.baynetworks.com Sent: Friday, February 09, 2001 7:32 AM Subject: Test Test I'm just testing the mail server because it appears alot of people are not receiving mail. Test 2: from internal Nortel account ------------------------------------------------------------------------ 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_01C092AD.525F03D0 Content-type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Test
Jiwoong,
 
I apologize=20 for not letting everyone know what was happening.  I have no = excuse except=20 for being an idiot.  Anyway, what is happening is that the owner = of the=20 mail server no longer has the resources to handle everything so the = Mobile IP=20 mailing list was moved to a different server and this server is running = majordomo instead of listserv.  From the end user perspective this = should=20 not change too much because the mail aliases have stayed the = same. =20 However, the problem we are seeing is some people are not getting the = mail=20 because their mail servers are returning the mail with "too many hops"=20 errors. 
 
The problem=20 should be fixed today.  I will let everyone know when that=20 happens.
 
-----Original Message-----
From: Jiwoong Lee=20 [mailto:porce@kaist.ac.kr]
Sent: Thursday, February 08, 2001 = 10:57=20 PM
To: Young, Ron [RICH1:IP21:EXCH]
Subject: Re:=20 Test

Sir,
 
Would you please explain = what happend to this mobile=20 IP ML if you are somewhat connected to this administration = ?
 
 
Thank you,
(And posting to ML = please.)
 
----- Original Message ----- =
From:=20 Ron Young
To: mobile-ip@marv= in.corpeast.baynetworks.com=20
Sent: Friday, February = 09, 2001 7:32=20 AM
Subject: Test

Test

I'm just testing the mail server because it appears = alot of=20 people are not receiving mail. 

Test 2: from internal Nortel account

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

------_=_NextPart_001_01C092AD.525F03D0-- From ronyoung@nortelnetworks.com Fri Feb 9 11:25:18 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22177 for ; Fri, 9 Feb 2001 11:25:17 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Fri, 9 Feb 2001 09:41:01 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Fri, 9 Feb 2001 09:42:39 -0600 Received: from zrchh190 (zrchh190.us.nortel.com [47.158.65.22]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id KAA22753 for ; Fri, 9 Feb 2001 10:38:50 -0500 (EST) Received: from smtprch1.nortel.com (actually erchg0j) by zrchh190; Fri, 9 Feb 2001 09:40:02 -0600 Received: from zcard00n.ca.nortel.com by smtprch1.nortel.com; Fri, 9 Feb 2001 09:38:29 -0600 Received: from pnshy001.us.nortel.com ([47.158.12.167]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 1QMB3CAR; Fri, 9 Feb 2001 10:38:23 -0500 Received: from hnshp0px (hnshp0px.us.nortel.com [47.55.91.130]) by pnshy001.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DTYJ6SKT; Fri, 9 Feb 2001 09:38:20 -0600 Message-ID: <200102090937130980.07B6349F@pnshy001.us.nortel.com> In-Reply-To: References: X-Mailer: Calypso Version 3.10.03.02 (3) Date: Fri, 09 Feb 2001 09:37:13 -0600 X-Sybari-Space: 00000000 00000000 00000000 From: "Joe Creel" To: "Ron Young" , "'Jiwoong Lee'" Cc: mobile-ip@marvin.corpeast.baynetworks.com, "'phil.roberts@motorola.com'" , "'Basavaraj.Patil@nokia.com'" Subject: RE: Test Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====_9817330339961=_" X-Orig: X-Orig: X-Orig: --=====_9817330339961=_ Content-Type: text/plain; charset="us-ascii" Ron; Can I get one of the NDR related to this....I am the one to complain to concerning e-mail routing and the majordomo server now.... thanks Joe *********** REPLY SEPARATOR *********** On 2/9/01 at 9:31 AM Young, Ron [RICH1:IP21:EXCH] wrote: Jiwoong, I apologize for not letting everyone know what was happening. I have no excuse except for being an idiot. Anyway, what is happening is that the owner of the mail server no longer has the resources to handle everything so the Mobile IP mailing list was moved to a different server and this server is running majordomo instead of listserv. From the end user perspective this should not change too much because the mail aliases have stayed the same. However, the problem we are seeing is some people are not getting the mail because their mail servers are returning the mail with "too many hops" errors. The problem should be fixed today. I will let everyone know when that happens. ------------------------------------------------------------------------ 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. -----Original Message----- From: Jiwoong Lee [mailto:porce@kaist.ac.kr] Sent: Thursday, February 08, 2001 10:57 PM To: Young, Ron [RICH1:IP21:EXCH] Subject: Re: Test Sir, Would you please explain what happend to this mobile IP ML if you are somewhat connected to this administration ? Thank you, (And posting to ML please.) ----- Original Message ----- From: Ron Young To: mobile-ip@marvin.corpeast.baynetworks.com Sent: Friday, February 09, 2001 7:32 AM Subject: Test Test I'm just testing the mail server because it appears alot of people are not receiving mail. Test 2: from internal Nortel account ------------------------------------------------------------------------ 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. --=====_9817330339961=_ Content-Type: text/html; charset="us-ascii" Test
Ron;
 
Can I get one of the NDR related to this....I am the one to complain to concerning e-mail routing and the majordomo server now....
 
 
thanks
Joe

*********** REPLY SEPARATOR ***********

On 2/9/01 at 9:31 AM Young, Ron [RICH1:IP21:EXCH] wrote:
Jiwoong,
 
I apologize for not letting everyone know what was happening.  I have no excuse except for being an idiot.  Anyway, what is happening is that the owner of the mail server no longer has the resources to handle everything so the Mobile IP mailing list was moved to a different server and this server is running majordomo instead of listserv.  From the end user perspective this should not change too much because the mail aliases have stayed the same.  However, the problem we are seeing is some people are not getting the mail because their mail servers are returning the mail with "too many hops" errors. 
 
The problem should be fixed today.  I will let everyone know when that happens.
 
------------------------------------------------------------------------
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.
-----Original Message-----
From: Jiwoong Lee [mailto:porce@kaist.ac.kr]
Sent: Thursday, February 08, 2001 10:57 PM
To: Young, Ron [RICH1:IP21:EXCH]
Subject: Re: Test

Sir,
 
Would you please explain what happend to this mobile IP ML if you are somewhat connected to this administration ?
 
 
Thank you,
(And posting to ML please.)
 
----- Original Message -----
From: Ron Young
Sent: Friday, February 09, 2001 7:32 AM
Subject: Test

Test

I'm just testing the mail server because it appears alot of people are not receiving mail. 

Test 2: from internal Nortel account

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

--=====_9817330339961=_-- From ronyoung@nortelnetworks.com Fri Feb 9 20:58:05 2001 Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06138 for ; Fri, 9 Feb 2001 20:58:04 -0500 (EST) Received: from zrchh190 by smtprch2.nortel.com; Fri, 9 Feb 2001 19:26:44 -0600 Received: from marvin.corpeast.baynetworks.com by zrchh190; Fri, 9 Feb 2001 18:17:40 -0600 Received: from zrtps06t.us.nortel.com (zrtps06t.us.nortel.com [47.140.48.51]) by marvin.corpeast.baynetworks.com (8.8.8+Sun/8.8.8) with ESMTP id TAA05739; Fri, 9 Feb 2001 19:04:12 -0500 (EST) Received: from 47.234.0.31 (actually ertpsms1.internet.nortel.com) by zrtps06t; Fri, 9 Feb 2001 19:03:23 -0500 Received: from NEPTUNE.zucotto.com ( [216.95.209.154]) by with SMTP (MailShield v1.5); Fri, 09 Feb 2001 19:04:23 -0500 Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21) id ; Fri, 9 Feb 2001 19:02:32 -0500 Message-ID: From: Kulwinder Atwal To: "'zeroconf@merit.edu'" , seamoby@cdma-2000.org, MOBILE-IP@marvin.corpeast.baynetworks.com, "'srvloc@srvloc.org'" , "'aaa-wg@merit.edu'" , "'manet@itd.nrl.navy.mil'" , "'ipsec@lists.tislabs.com'" , "'ipsec-policy@vpnc.org'" , "'ietf-ipsra@vpnc.org'" , "'ietf-sacred@imc.org'" , "'enum@ietf.org'" , sigtran@marvin.corpeast.baynetworks.com, "'ietf@ietf.org'" , "'IETF-Announce@ietf.org'" , "'BLUETOOTH-BOF@mailbag.cps.intel.com'" Cc: "'Thomas Narten'" , Akers Ron-WRA001 Subject: BOF: IP over Bluetooth for 50th Meeting of IETF. Date: Fri, 9 Feb 2001 19:02:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: NEPTUNE.zucotto.com X-SMTP-MAIL-FROM: kulwinder.atwal@zucotto.com X-SMTP-RCPT-TO: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM,sigtran@standards.nortelnetworks.com X-SMTP-PEER-INFO: [216.95.209.154] X-Orig: X-Orig: X-Orig: Myself and Ron Akers have requested an IP over Bluetooth BOF for the 50th Meeting of the IETF in Minneapolis. The BOF will discuss the creation of a IETF Working Group to investigate the most open and efficient way to place IP over the Bluetooth Host Controller. Current work in this area within the Bluetooth SIG concentrates on defining IP over a set of other lower-layer stacks. Currently there are two options defined by the Bluetoth SIG: Option 1: IP/PPP/RFCOM/L2CAP/Host Controller Option 2: IP/PAN Profile/L2CAP/Host Controller (where the PAN Profile is a Bluetooth SIG work in progress) We are proposing that the IETF form a WG to define a more efficient way of running IP over Bluetooth. In particular, IP would run over an IETF protocol over the Host Controller without L2CAP. This option may be adopted by the Bluetooth SIG at a later date as a Profile. Since all Bluetooth SIG Profiles are optional, a customer may choose any combination of Profiles in a final product. Further, since Bluetooth Working Groups have it in their mandate to adopt protocols from other standards making bodies such as the IETF, there exists a clear path for IETF work to be adopted by the Bluetooth SIG. Whereas the last BOF was informational only and organized by the Bluetooth SIG itself, the objective of this BOF will be to foster innovation, and speed progress by placing IP related protocol development wihin the IETF and Bluetooth-specific protocol development within the Bluetooth SIG, by developing an IP over Bluetooth IETF Working Group. This effort will define its own way of running IP over Bluetooth, by carefully selecting a set of Bluetooth protocols (freely available from published specifications at http://www.bluetooth.com/developer/specification/specification.asp) on which to build IP. Please join myself, Kulwinder Atwal, and Ron Akers on the pre-BOF mailing list: This site runs version 2.0.1 of the "Mailman" list manager. The following describes commands you can send to get information about, and control your subscription to the lists at this site. Note that much of the following can also be accomplished via the World Wide Web, at: http://internet.motlabs.com/mailman/listinfo/bluetooth In particular, you can use the Web site to have your password sent to your delivery address. Email commands can be in the subject line or in the body of the message. The commands should be set to the following address: About the descriptions - words in "<>"s signify REQUIRED items and words in "[]" denote OPTIONAL items. Do not include the "<>"s or "[]"s when you use the commands. The following commands are valid: subscribe [password] [digest-option] [address=
] Subscribe to the mailing list. Your password must be given to unsubscribe or change your options. When you subscribe to the list, you'll be reminded of your password periodically. 'digest-option' may be either: 'nodigest' or 'digest' (no quotes!) If you wish to subscribe an address other than the address you send this request from, you may specify "address=" (no brackets around the email address, no quotes!) unsubscribe [address] Unsubscribe from the mailing list. Your password must match the one you gave when you subscribed. If you are trying to unsubscribe from a different address than the one you subscribed from, you may specify it in the 'address' field. who See everyone who is on this mailing list. info View the introductory information for this list. lists See what mailing lists are run by this Mailman server. help This message. set