Subject: RE: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt

From: Tsirtsis George <[email-masked]>
Date: Wed, 30 Jul 2003 04:48:20 -0400

Alain,

For mobility a node needs a stable address i.e. the Home Address (HoA). All
communications are directed to that HoA and a Home Agent (HA) intercepts and
forwards to the node's care-of-address (CoA).

Now how the Mobile node comes to own a given HoA is not so important from
this perspective. It could be native v6 or it could be 6to4...I do not think
it matters as long as there is an HA that can intercept packets sent to that
HoA and forward them to the CoA.

Now, when the mobile is  not at home but in some other network, there is an
issue about what kind of v4/v6 support there is in the foreign network. The
nice thing about Mobile IP is that it is based on tunnels and thus it
provides natural way of tunneling over networks that are not compatible with
the mobile ...if only Mobile IP could configure v4 over v6 and v6 over v4
tunnels (as opposed to just v4 over v4 and v6 over v6 tunnels). A dual stack
mobile in a v4 only foreign network would then be able to create a v4&v6
over v4 (forward and reverse) tunnel with its HA and thus maintain all its
connectivity.

George

-----Original Message-----
From: Alain Durand [mailto:[email-masked]] 
Sent: Wednesday, July 30, 2003 12:23 AM
To: Tsirtsis George
Cc: Mobile-Ip ([email-masked]); [email-masked]; Soliman
Hesham; 'Thomas Narten'
Subject: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-00.txt

Hi George,

Thank you for writing this draft, this is an interesting perspective. There
is one point you do not mention: what if the IPv6 node is using directly or
indirectly IPv6 in IPv4 tunnels for its IPv6 connectivity? For example, it
may derive a 6to4 prefix from its home address and then uses MIPv4.... There
are extra complexities here that I'm not sure I fully understand. Is it a
problem space that you intend to cover?

	- Alain.

On Tuesday, July 29, 2003, at 12:17  PM, Tsirtsis George wrote:

> Hi all,
>
> During the Mobile IP WG meeting in Austria, Hesham and myself brought
> up the
> issue of mobility management for dual stack nodes.
>
> Thomas N. requested that we put together a problem statement so that
> we can
> discuss the issue; the draft below was published today - it is short 
> and I
> hope to the point - so do read it :)
>
> I have copied v6ops since I think this is a v4 - v6 migration issue as
> well
> as Mobile IPv4 and Mobile IPv6 issue.
>
> Let us know what you think.
>
> George
>
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, July 29, 2003 5:15 PM
> Subject: I-D ACTION:draft-tsirtsis-dsmip-problem-00.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>
> 	Title		: Mobility management for Dual stack mobile nodes  A
>
>                           Problem Statement
> 	Author(s)	: G. Tsirtsis, H. Soliman
> 	Filename	: draft-tsirtsis-dsmip-problem-00.txt
> 	Pages		: 4
> 	Date		: 2003-7-29
> 	
> This draft discusses the issues associated with mobility management 
> for dual stack mobile nodes. Currently, two mobility management 
> protocols are defined for IPv4 and IPv6. Deploying both in a dual 
> stack mobile node introduces a number of inefficiencies. Deployment 
> and operational issues motivate the use of a single mobility 
> management protocol. This draft discusses such motivations. The draft 
> also hints on how current MIPv4 and MIPv6 could be extended so that 
> they can support mobility management for a dual stack node.
>
> A URL for this Internet-Draft is: 
> http://www.ietf.org/internet-drafts/draft-tsirtsis-dsmip-problem-00.tx
> t
>
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body of the 
> message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in, 
> type
> "cd internet-drafts" and then
> 	"get draft-tsirtsis-dsmip-problem-00.txt".
>
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-tsirtsis-dsmip-problem-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader 
> implementation to automatically retrieve the ASCII version of the 
> Internet-Draft.
>
>
> Date: Tue Jul 29, 2003  9:40:01  AM US/Pacific
> To:
> Subject:
>
>
>
> <ATT19898.txt>
>

---

From: Fred Templin <[email-masked]>
Date: Wed, 30 Jul 2003 09:52:53 -0700

George,

>over v4 (forward and reverse) tunnel with its HA and thus maintain all its
When a dual-stack MIPv6 MN encounters a v4-only foregin network,
I see (at least) three possibilities for the v6-in-v4 tunnel endpoint:

 1) the tunnel endpoint resides in the home network; perhaps
    even co-located with the HA (potential use case for configured
    tunnels)

 2) the tunnel endpoint resides in the visited netwok (potential
    use-case for isatap)

 3) the tunnel endpoint resides in some 3rd party network
    (potential use-case for tunnel broker)

In any case, the v6-in-v4 tunnel should present an MTU large enough
to encapsulate 1280 bytes PLUS the size of the outermost IPv6 header
so that the inner MIPv6  IPv6-in-IPv6 tunneling does not incur harmful
fragmentation (see RFC 2473, section 7). But, most v6-in-v4 tunneling
specifications cap their MTUs at 1280 bytes. Does this seem like a
potential performance issue waiting to bite us?

Fred
[email-masked]

---

From: Alain Durand <[email-masked]>
Date: Wed, 30 Jul 2003 10:18:44 -0700

> over v4 (forward and reverse) tunnel with its HA and thus maintain all 

Call me skeptic, but I am a little concern with the potential effect of 
double or
even worse  triple tunneling: Mipv6/Ipv6/Mipv4/IPv4
and I'm sure we could build scenarios even more frightening with various
combination of encapsulation.
I'm not worried about MTU, but about RTT and debugging.

	- Alain.

---

From: Fred Templin <[email-masked]>
Date: Wed, 30 Jul 2003 10:30:07 -0700

> I'm not worried about MTU, but about RTT and debugging. 

Perhaps except to the extent that MTU and RTT/debugging
may be inter-related?

Fred
[email-masked]