Subject: Re: Operating environments [RE: (ngtrans) Next steps]

From: "Liu, Changwen" <[email-masked]>
Date: Mon, 8 Apr 2002 15:37:02 -0700

Tony,
I would like to bring to closure the discussion thread on the draft
draft-ietf-ngtrans-moving-01.txt> (<MOVING> hereafter) and my draft
<draft-liu-mobileip-mipv6overmipv4-00.txt> ( <mipv6overmipv4> hereafter),
and get the opinions of the chairs on proposed next steps.

In the absence of a requirements draft for appropriate handling of mobile
IPv4 and IPv6 transition mechanisms in this WG, the two drafts <MOVING> and
<mipv6overmipv4> have proposed/studied solutions with slightly different but
complementary goals. Draft <MOVING> lists all scenarios that might occur for
a mobile node in a transition network and evaluates the support of current
transition mechanisms. The goal of draft <mipv6overmipv4> is to solve a
particular class of problems: how to allow Mobile IPv6 nodes at a 6to4 site
to continue utilizing Mobile IPv6 services when they roam into IPv4-only
domains. In terms of covered scenarios, draft  <mipv6overmipv4> complements
draft <MOVING> in two (what we believe are) important scenarios as
elaborated below. The draft <MOVING> lists all handoff combinations for a
mobile node and its located networks and suggests existing mechanisms that
can be applied to enable communication with correspondent hosts. But for the
listed case of a dual stack (DS) mobile IPv6 MN (MNv6) moving to an
IPv4-only network, the analysis makes the following 2 assumptions:

1. DS MNv6 must get a co-located local IPv4 address (care-of address or COA)
in visited network, and
2. MNv6's MIPv6 HA must have both IPv6 and IPv4 addresses.

In other words, the two scenarios where 

* DS MNv6 can only get a FA-located COA in a visited network (e.g. public
WLAN hot spot) and 
* MNv6's MIPv6 HA does not have an IPv4 address (possible in an operator
network due to limited IPv4 addresses)

are not covered in draft <MOVING>. 

Draft <mipv6overmipv4> covers these two missing scenarios and hence
complements the draft <MOVING>. Although the draft <mipv6overmipv4>
discusses 6to4 sites, it is possible to generalize to other cases. With 6to4
being widely deployed, this becomes an important consideration.

Now the question is how important are the two scenarios - where DS MNv6 can
only get a FA-located COA in visited network and MNv6's MIPv6 HA does not
have an IPv4 address. Some reasons why we feel these scenarios are important
are:

* For the scenario where the DS MNv6 can only get a FA-located COA in the
visited network, we can take a look at the possible Mobile IP deployment in
GPRS/3G networks. 3GPP document TR 23.923 specifies a way of using Mobile IP
as a tunneling and mobility management protocol in (an IPv4-only?) GPRS/UMTS
network. In that document, the GGSN can be enhanced with a co-located FA to
support Mobile IP as a mobility management protocol. Furthermore, the
document specifies that "As IPv4 addresses and radio resources are scarce,
Foreign Agent care-of addresses are preferred for UMTS/GPRS" for mobile
nodes in GPRS/UMTS network. So its likely that the FA-located COA will be
preferred in a GPRS/UMTS network. In other words, we should at least expect
non-zero deployment or more likely significant deployment for FA-located COA
support in IPv4-only GPRS/UMTS networks. When an MNv6 moves into such
networks, it may only get a FA-located COA, instead of co-located COA. An
email with some deployment info from Nextel is attached as further
reference.

* Again for the scenario where DS MNv6 can only get a FA-located COA in
visited network, we can also take a look at a real Mobile IP deployment
example. Currently, Nextel has full Mobile IP deployment in US (see attached
two emails I got from mobile-ip and seamoby lists). As of 2001, Nextel has
~20 HA and ~200 FAs and *All* of Nextel's data subscribers are Mobile IP
clients. HA-FA Tunnels are built nation-wide. So it is very clear that
mobile nodes (MNv6) moving into such Nextel network may only get FA-located
COA.

* For the scenario where the MNv6's MIPv6 HA does not have an IPv4 address,
we can take a look at a 6to4 site that is big enough to have at least two
different IPv4? subnets but however only has one IPv4 routable address at
its border router as an example. In this case, not all MNv6s' MIPv6 HAs will
have IPv4 address.

If you agree that the two scenarios must be covered, IMHO, there are two
ways to move ahead. 

1. Either we write a separate requirements draft that captures all the
requirements for mobility support during the transition period, including
the above two missing scenarios, and the two drafts are positioned as simply
presenting solutions to the requirement draft or
 
2. We make the draft <MOVING> more complete by at least including the
problem description for the two missing scenarios. In this case, draft
<MOVING> could provide a reference/pointer to draft <mipv6overmipv4> or the
2 drafts could be merged with the authors being the union of the two drafts'
authors.

I look forward for your comments.

Kind Regards,
changwen

> -----Original Message-----
> From: Shiao-Li Tsao (Charles) [mailto:[email-masked]]
> Sent: Thursday, March 28, 2002 7:38 PM
> To: Liu, Changwen
> Cc: [email-masked]
> Subject: Re: Operating environments [RE: (ngtrans) Next steps]
> 
> 
> ------deleted
> > The draft <mipv6overmipv4> also complements <MOVING> in 
> this configuration
> > requirement aspect as detailed in the following two bulletins.
> > 1. Asking every MIPv6 HA having an IPv4 address may be too luxury to
> afford
> > (due to demands for IPv4 addresses) or impractical (imagine a big
> IPv6-only
> > site: now potentially every router within the site needs to 
> have an IPv4
> > address and however IPv4 routing is not supported within 
> the site). On the
> > other hand, <mipv6overmipv4> doesn't require MIPv6 HA 
> having IPv4 address.
> > 2. The draft <MOVING> depends on TEP: dedicated TEP needs 
> to be deployed
> and
> > that implies DSTM specified in draft 
> draft-ietf-ngtrans-dstm-07.txt may
> need
> > to be deployed. I see debates for NAT-PT vs DSTM still 
> going on in this
> WG.
> > On the other hand, <mipv6overmipv4> depends on 6to4 that is 
> a RFC now.
> >
> >
> > In summary, <mipv6overmipv4> covers scenarios that are not 
> covered by
> > <MOVING> and these scenarios are important and cannot be ignored.
> >
> > My two cents.
> >
> > changwen
> 
> I would like to comment some important points which should 
> not be confused
> in the mailing list.
> The first thing that a MN moves to an IPv4-only network 
> should be get the
> IPv6 connectivities first such as 6over4, shipworm, 
> mip-nat-travesal etc do.
> In that way, MN can tunnel their packets to HA through tunnel 
> points (can be
> HA or any points). HA is not required IPv4 address if there 
> is a tunnel
> point in between.
> IMO, to work on new mechanisms or new requirements on any 
> node dealing with
> MIPv4 & MIPv6 should be left as the second priority (and if 
> the scenario we
> really need).
> Please don't compare <MOVING> and <mipv6overmipv4> anymore, 
> their goals are
> quite different.
> What we do in <MOVING> is to list all scenarios that might happend for
> mobile node in a transition network and to evaluate the 
> supports of current
> tools. We will list the requirements and limitations.
> 
> Charles
> 
> 
>

---

From: "Shiao-Li Tsao \(Charles\)" <[email-masked]>
Date: Tue, 9 Apr 2002 11:49:11 +0800

Some comments about the assumptions and scenarios ...

----- Original Message -----
From: "Liu, Changwen" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, April 09, 2002 6:37 AM
Subject: Re: Operating environments [RE: (ngtrans) Next steps]

> 2. MNv6's MIPv6 HA must have both IPv6 and IPv4 addresses.

Charles > If DS MNv6 can get IPv6 connectivities in IPv4 network through
6over4, shipworm, mip-nat-travesal etc or know any tunneling point, DS MNv6
can send BU to MIPv6 HA. Then, MIPv6 HA does not require to have an IPv4
address in these situations.

> * DS MNv6 can only get a FA-located COA in a visited network (e.g. public

Charles > I don't think it is a pratical assumption in public WLAN hot spot.
In public WLAN hot spot, I will imagine that MN can get IPv4 local address
via DHCP inside NAT. In this case, we can use shipworm or mip-nat-travelsal
to send BU to HA.

> email with some deployment info from Nextel is attached as further

Charles > For DS MNv6 moves to GPRS/3G networks but still wants to use its
IPv6 address, GPRS/3G network should at least support IPv6 on GGSN. (MN
should specify protocol type as IPv6 while doing PDP context
activation.Follow by PDP context activation, a set of IPv6 autoconfiugration
procedures is required.). That is not an IPv4-only network.

Charles