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.
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.
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/=
A>=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
?
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