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

From: "Liu, Changwen" <[email-masked]>
Date: Fri, 12 Apr 2002 11:19:48 -0700

I am still waiting for the response from Chairs on my original request. 

However for not confusing other people, I would like to clarify the things a
little bit. See my response inserted in the following message.

changwen

> -----Original Message-----
> From: Shiao-Li Tsao (Charles) [mailto:[email-masked]]
> Sent: Monday, April 08, 2002 8:49 PM
> To: Liu, Changwen; Tony Hain
> Cc: [email-masked]; Alain Durand; 
> [email-masked]; Margaret
> Wasserman
> Subject: Re: Operating environments [RE: (ngtrans) Next steps]
> 
> 
> 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]
> 
> 
> > 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.
> 
> 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.
> 

I saw you made such claims before but I have never seen you being able to
document them in the latest draft <MOVING>. There are problems there and I
can see many of them. You better figure out details and
issues/assumptions/complexity with them and document them clearly if you
think you can cook a solution (for which I doubt) before you make such
claims again. That MIPv6 HA must have both IPv6 and IPv4 addresses remains
an issue at least now and IMO, will remain an issue for the draft <MOVING>.

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

In public WLAN hot spot case, obviously there will be situations that need
and support FA-located COA. In the situations where MNv6 gets private IPv4
address, can you show to me how you use techniques such as mip-nat-travelsal
to create a solution? What complex city/assumptions/issues you need to have
with shipworm?

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

GPRS which is based on TS 23.121 and TS 23.060 (Rel 99) supports IPv4 only
network and MIPv4 deployed in GPRS very likely supports FA-located COA only.
In 3G network, if IPv6 capability is not turned on, the 3G network remains
an IPv4 only network. As more and more GPRS and 3G network are being rolled
out now in US and other countries, I expect to see new, i.e. non-zero
deployment of, IPv4 only and more likely MIPv4 networks in GPRS and 3G
networks that support FA-located COA. As mentioned earlier, Nextel in US
(which, I believe, is based on 3GGP2) is another practical example that may
have FA-located COA only. 

> Charles

changwen

> 
> 
> 
> 
> >
> > * 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: "Tony Hain" <[email-masked]>
Date: Mon, 15 Apr 2002 08:57:01 -0700

> I am still waiting for the response from Chairs on my

Sorry for the late reply, we have been putting our effort into getting
organization around documents describing specific environments. As such
documents describing approaches to potential problems don't get much
attention.

> > Draft <MOVING> lists all scenarios
> > that might occur for
> > > transition mechanisms.

While this document starts off well at describing the potential set of
environments, it quickly degrades into describing an overly complex set
of mechanisms intended to make an unlikely set of scenarios possible.
NGtrans should be describing how a node that appears in a domain gets
addressed, and connected to the world. The mobility of aspects of that
node are out of scope.

> > The goal of draft <mipv6overmipv4> is to solve a
> > nodes at a 6to4 site
> > > domains.

As far as I can tell, the only job of NGtrans here is to describe how a
ds-IPv6 node acquires an address and connectivity when it is in an
IPv4-only domain. How that node chooses to use it as a care-of address
is the problem of the Mobile-IP WG. In particular, any contortions
involving mip-over-mip are *way out of scope*.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 17 Apr 2002 11:44:45 -0700

Just checking to see if I can post to this list again... Tony