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

From: "Liu, Changwen" <[email-masked]>
Date: Thu, 28 Mar 2002 17:36:24 -0800

> -----Original Message-----
> From: Shiao-Li Tsao (Charles) [mailto:[email-masked]]
> Sent: Thursday, March 28, 2002 4:28 PM
> To: Liu, Changwen
> Cc: [email-masked]
> Subject: Re: Operating environments [RE: (ngtrans) Next steps]
> 
> 
> > > Assumption :
> > > 1. dual stack mobile with an IPv6 home address but without
> > > IPv4 home address
> > > (have IPv4 temporary address)
> > > 2. move from dual stack network or IPv6-only network to
> > > IPv4-only network,
> > > and still can be reached by its IPv6 home address.
> > >
> > > Some possible apporaches we can do now is
> > > (1). if there is 6over4, using 6over4, perform MIPv6 BU to HA.
> >
> > One cannot expect (legacy) IPv4 domain support 6over4.
> >
> > > (2). if there is no (1), get an IPv4 temporary address as
> > > CCoA (via DHCP,
> > > ...)
> >
> > Again that goes back to the square one: MNv6 requires to 
> get a co-located
> > IPv4 CoA. Otherwise, it won't work, e.g. even for the case 
> that MNv6 can
> get
> > FA's CoA. This requirement certainly WORSENS the IPv4 
> address depletion
> > issue :-(. In other words, this requirement is significant.
> >
> 
> Yes. Based on current ngtrans tools, what we can do now is to 
> get a global
> v4 CCoA and tunnel to HA. If a global v4 CCoA is not 
> available, then get a
> private CCoA and uses it in combination with UDP tunneling 
> and keep-alives
> technique described in "Mobile IP NAT/NAPT Traversal using UDP
> Tunnelling"<draft-ietf-mobileip-nat-traversal-01.txt> and 
> back to HA. We are
> going to describe this scenario in the next version of 
> <MOVING>. By the way,
> <draft-ietf-mobileip-nat-traversal-01.txt> is not yet a RFC, 
> we would not
> dig into detail at current stage.
> 

BTY, that's where the draft <mipv6overmipv4> fits in. In addition to the
case in that MNv6 has local co-located COA, the mechanism in
<mipv6overmipv4> also works for the case in that MNv6 only has local FA COA.
In other words, as long as MNv6 gets a local COA in visited IPv4 domain,
MNv6 that employs <mipv6overmipv4> still works. So the draft
<mipv6overmipv4> complements <MOVING> for this important scenario. 

FYI, if MNv6 cannot get local COA in the visited IPv4 domain (e.g. an
IPv4-only domain without any IPv6 routing fabric), I don't think any
mechanism will work. So obtaining a local COA for MNv6 is the minimal
requirement for MNv6 to work.

> 
> > > (3). encapsulated MIPv6 BU in IPv4 packet and send it to HA
> > > (here we assume
> > > MN knows any TEP v4 address or HA v4 address (via HA advert.) )
> >
> > Isn't the TEP like MIPv4 HA minus MIPv4 registration 
> procedure? In other
> > words, the third entity other than MNv6 and its MIPv6 HA has to be
> involved.
> 
> 
> That is two options. If you have IPv4 address of MIPv6 HA, 
> tunnel the packet
> to the MIPv6 HA directly. Or if MN knows any TEP v4 address, 
> tunnel the
> packet to the MIPv6 HA through TEP. If you don't have an IPv4 
> address of any
> node which can decapsulate IPv6 in IPv4 packet, MNv4 can not 
> send any IPv6
> packet out in a IPv4-only network.

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.

> Charles

In summary, <mipv6overmipv4> covers scenarios that are not covered by
<MOVING> and these scenarios are important and cannot be ignored. 

My two cents.

changwen

> >
> > > (v4 source address : MN CCoAv4, v4 desination : TEPv4 (or
> > > HAv4), (MIPv6
> > > BU)). At HA, MN CCoA v4-compatible v6 address is now IPv6 CoA.
>

---

From: "Shiao-Li Tsao \(Charles\)" <[email-masked]>
Date: Fri, 29 Mar 2002 11:37:57 +0800

------deleted
> <MOVING> and these scenarios are important and cannot be ignored.

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