Subject: [Mip6] DSMIP accommodation of split of v4 and v6 home link ?

From: <[email-masked]>
Date: Wed, 10 Oct 2007 09:51:44 +0200

Hi Hesham, All 

With the aim to clarify better. 

In the 3GPP LTE/SAE network, under final specification, 
 mobility of the user equipment (UE) is realized using 
different IETF mechanisms: MIP, DSMIP, ProxyMIP, and 
IPv4-ProxyMIP, all centered on a home agent (HA) functionality 
and local mobility anchor (LMA) functionality in the packet data 
network gateway (PDN GW), and mobile access gateway functionality 
in the serving gateway (Serving GW), and mobile node functionality 
in the UE.  The UE can be attached to the 3GPP in the following ways. 

 * UE can have so-called 3GPP access, and this is found in two 
   variants: 
    * either the Serving GW hosts the mobile access gateway 
      functionality and the PDN GW hosts the corresponding 
      local mobility anchor functionality, 
    * or the Serving GW realizes ordinary GTP tunnels which are 
      terminated in the PDN GW and the PDN GW hosts corresponding 
      home agent functionality. 
   The UE does not know which variant is used, as it only sees a 
   PDP context.  This network is denoted the AA network. 

 * UE can have non-3GPP access with network-based mobility.  In 
   this instance the mobile access gateway functionality is 
   hosted in either the access gateway of the non-3GPP access network 
   or in the evolved packet data gateway (ePDG), while the corresponding
local 
   mobility anchor functionality is hosted in the PDN GW.  
   This network is denoted the BB network. 

 * UE can have non-3GPP access with host-based mobility, in which 
   case the mobile node uses DSMIP while the PDN GW hosts the 
   corresponding home agent functionality.  This network is 
   denoted the CC network. 

>From a IP mobility perspective there is not much difference in between
AA and BB. 
The notably difference in between the networks are 
* the possible usage of GTP in AA 
* potential difference in IPv6 and IPv4 access support 

In both networks, then from a IP mobility perspective, all user layer IP
access addresses provided to 
the UE are home addresses and the address allocation is administratively
controlled by the 
PDN GW which will ensure that the access addresses given out are the
same on the two networks. 

As addresses are carried over in between the AA and all BB networks, the
UE 
IPv6 home link spreads over potentially multiple BB networks and one AA
network. 
Likewise for the IPv4 Home link. 

The CC network is always, IP mobility wise, a foreign network. 

The peculiar situation that we would like to support is the situation, 
presumably primarily a transition period, where the AA network 
or the BB network (or both) does not support IPv6 access addresses. 

But where still: 
* the UE uses an IPv6 HoA for DSMIPv6 signaling (obviously, this is a
MUST) 
* the UE may roam in between AA and BB using an IPv4 HoA 
* the UE may use DSMIPv6 to roam in and out of CC 
* the UE may use DSMIPv6 to roam in between the AA network and BB
networks with different 
IP access (plus/minus IPv6) capabilities. 

If neither of the networks (AA and BB) supports IPv6 access, then 
the UE will never be at home IPv6 wise. 

Conceptually the AA and the BB networks run network based mobility on
IPv4 access 
but when IPv6 access cannot be provided, then 
the idea is to use DSMIPv6 in parallel to manage IPv6 mobility. 

This represents a logical split of the IPv4 and the IPv6 home link. 

Lack of deployment of IPv6 is one motivation for offering only 
an IPv4 PDP context in the 3GPP access (AA network).  Another motivation
is 
to limit the use of radio resources.  Thus, even if the network 
in general is IPv6 capable, full capability may only be offered 
via non-3GPP access (BB or CC) with sufficient bandwidth. 

Based on this overall scenario description, and looking into DSMIP and
its interaction with 
PMIPv6 and IPv4-PMIPv6, the functionality which we are after and 
which we cannot find explicitly described anywhere, is to allow DSMIPv6
to operate more 
independently on the v6HoA and v4HoA cache entries. Specifically so 
that a UE may use DSMIPv6 to signal 
* deregistration of an v4HoA registration 
* registration(update) of v6HoA DSMIPv6 registration to care-of-address
equal v4Hoa 
in one and the same DSMIPv6 BU. 

To go more into the details with some examples: 

Example scenario 1: 

An UE boots up in the CC network, then moves to the BB network. 
We want to have IPv6 connectivity to the UE, because the PDN GW is
connected to the 
IPv6 Internet as well as in order merely to use DSMIPv6 signaling, 
but we assume the BB and CC networks have IPv4 access connectivity only.

This scenario also covers the case where the network mobility in 
network AA is controlled using PMIP. 

First, the UE boots up in the CC network, an IPv4-only foreign network. 
During this booting, the UE is given an IPv4 care-of address (v4CoA), 
later it is provided with IPv4 and IPv6 home addresses (v6HoA, v4HoA)
via 
a combination of an IKEv2 exchange to HA (v6HoA allocation) and a
request for v4HoA 
sent in a DSMIPv6 BU to HA, registrating the (v6HoA, v4CoA)
relationship. 
The binding cache of the home agent will have the following two entries 

    home address of node    visited address of node 
    ----------------------------------------------- 
         v4HoA                    v4CoA 
         v6HoA                    v4CoA 

Second, the UE moves to the BB network, an IPv4-only network 
with proxy mobility.  Moving there, the mobile node is 
provided its IPv4 home address (v4HoA as above) as care-of-address, and
the 
mobile access gateway function sends a proxy binding update 
which rewrites the first line of the binding cache giving the 
mobile access gateway's IPv4 address (v4PCoA) as the visited 
address.  (The MAG address could also in theory be an IPv6 address
(v6PCoa), 
but this distinction is not important here). 
Now the cache looks as follows: 

home address of node    visited address of node 
    ----------------------------------------------- 
         v4HoA                    v4PCoA    marked as PMIPv6/IPv4-PMIPv6
controlled 
         v6HoA                    "old" v4CoA 

Or would PMIPv6 also manipulate the v6HoA entry, and if so, what would
it do - ? 

Anyway, the UE knows nothing about PMIPv6/IPv4-PMIPv6 and would 
like to send a BU de-registrating the v4HoA binding and refreshing the
v6HoA binding 
to use the v4HoA as IPv4 care-of-address. 
With the following desired result. 

    home address of node    visited address of node 
    ----------------------------------------------- 
         v4HoA                    v4PCoA marked as PMIPv6/IPv4-PMIPv6
controlled 
         v6HoA                    v4HoA  (DSMIPv6 controlled) 

The issues is how this should be done. Proposed options are described
further below. 
Please note that correctly manipulating the v6HoA binding cache entry is
required 
already alone to allow the HA to return the BACK. 

This will result in two tunnels for IPv6 traffic from HA to UE, the
outer tunnel 
from HA to MAG (v4PCoa) and the inner IPv6 in IPv4 tunnel to v4HoA and
as both tunnels originates in the HA 
this will require two consecutive look ups in the binding cache for Ivy
traffic. But well, that's how thing goes. 

Example scenario 2: 

An UE boots up in the CC network, then moves to the AA network where
host mobility is 
not done using PMIP (instead it is done using GTP). As above we want to
have IPv6 
connectivity to the UE, because the PDN GW is connected to the 
IPv6 Internet as well as in order merely to use DSMIPv6 signaling, 
but we assume the AA and the CC network have IPv4 access 
connectivity only. 

The address allocation and binding procedures in the CC is as in Example
1. 
With resulting Binding cache entries. 

home address of node    visited address of node 
    ----------------------------------------------- 
         v4HoA                    v4CoA 
         v6HoA                    v4CoA 

Second, the UE moves to the AA network, an IPv4-only network. 
Moving there, the mobile node is 
provided its IPv4 home address (v4HoA as above) as care-of-address. 
But without the involvement of PMIPv6 and the cache entries of the HA 
remains unaltered until the UE sends a DSMIPv6 BU. Again what the UE
would like 
is to send a BU deleting the v4HoA binding and refreshing the v6HoA
binding 
to use the v4HoA as IPv4 care-of-address. 
With the following desired result. 

    home address of node    visited address of node 
    ----------------------------------------------- 
         v6HoA                    v4HoA  

Again the issues is how this should be done. Proposed options are
described further below. 

Also please note that again, correctly manipulating the v6HoA binding
cache entry is required 
already alone to allow the HA to return the BACK. 

Proposed solution in DSMIPv6: 

The UE could send a binding update with some non-zero lifetime,
reporting v6HoA 
to be found at v4HoA (in IPv4 care-of-address option), and additionally
including v4HoA (in home address option) 
The home agent should conclude that the equality of the two IPv4
addresses means 
removal of the v4HoA cache entry. 
This does not imply changing any DSMIPv6 protocol messages, but it still
deserves some text to say how the HA 
should handle the situation when the v4HoA is the same as the CoA. 

Another approach is to be explicit and set a 
bit or a lifetime attached to the IPv4 address in the IPv4 Home Address
Option. 
Being explicit also indicates, that should a packet have 
the home address and the visited address equal, that 
packet is malformed. 

It is of course worth thinking about whether this scenario 
is relevant for the IETF to consider, but for 3GPP networks 
it will allow gradually introduction of IPv6 without modifying the
protocols. 

Christian/Karen

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 18 Oct 2007 00:37:03 +1000

Karen, Christian, 
 
Thanks for the write up. It's never boring with 3GPP's design choices but
unfortunately almost always sad....
Basically what you're describing is the result of making bad design choices
like allocating home addresses outside the home network and effectively
splitting the home network, while using every protocol under the sun at the
same time....sigh
Of course there are two ways of handling this: 1) This design breaks the
fundamental requirement of DSMIPv6, which is that the home link is
IPv6-enabled and therefore we don't need to address it or 2) allowing this
somehow, one way is obviously what you suggest. I'd like to hear some more
opionions on this. 
 
Hesham

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, October 10, 2007 5:52 PM
To: [email-masked]; [email-masked];
[email-masked]
Subject: DSMIP accommodation of split of v4 and v6 home link ?

Hi Hesham, All 

>From a IP mobility perspective there is not much difference in between AA
and BB. 

In both networks, then from a IP mobility perspective, all user layer IP
access addresses provided to 
the UE are home addresses and the address allocation is administratively
controlled by the 
PDN GW which will ensure that the access addresses given out are the same on
the two networks. 

As addresses are carried over in between the AA and all BB networks, the UE 
IPv6 home link spreads over potentially multiple BB networks and one AA
network. 
Likewise for the IPv4 Home link. 

But where still: 
* the UE uses an IPv6 HoA for DSMIPv6 signaling (obviously, this is a MUST) 
* the UE may roam in between AA and BB using an IPv4 HoA 
* the UE may use DSMIPv6 to roam in and out of CC 
* the UE may use DSMIPv6 to roam in between the AA network and BB networks
with different 
IP access (plus/minus IPv6) capabilities. 

Conceptually the AA and the BB networks run network based mobility on IPv4
access 
but when IPv6 access cannot be provided, then 
the idea is to use DSMIPv6 in parallel to manage IPv6 mobility. 

an IPv4 PDP context in the 3GPP access (AA network).  Another motivation is 

Based on this overall scenario description, and looking into DSMIP and its
interaction with 
PMIPv6 and IPv4-PMIPv6, the functionality which we are after and 
which we cannot find explicitly described anywhere, is to allow DSMIPv6 to
operate more 
independently on the v6HoA and v4HoA cache entries. Specifically so 
that a UE may use DSMIPv6 to signal 
* deregistration of an v4HoA registration 
* registration(update) of v6HoA DSMIPv6 registration to care-of-address
equal v4Hoa 
in one and the same DSMIPv6 BU. 

Example scenario 1: 

An UE boots up in the CC network, then moves to the BB network. 
We want to have IPv6 connectivity to the UE, because the PDN GW is connected
to the 
IPv6 Internet as well as in order merely to use DSMIPv6 signaling, 
but we assume the BB and CC networks have IPv4 access connectivity only. 

First, the UE boots up in the CC network, an IPv4-only foreign network. 
During this booting, the UE is given an IPv4 care-of address (v4CoA), 
later it is provided with IPv4 and IPv6 home addresses (v6HoA, v4HoA) via 
a combination of an IKEv2 exchange to HA (v6HoA allocation) and a request
for v4HoA 
sent in a DSMIPv6 BU to HA, registrating the (v6HoA, v4CoA) relationship. 
The binding cache of the home agent will have the following two entries 

Second, the UE moves to the BB network, an IPv4-only network 
with proxy mobility.  Moving there, the mobile node is 
provided its IPv4 home address (v4HoA as above) as care-of-address, and the 
mobile access gateway function sends a proxy binding update 
which rewrites the first line of the binding cache giving the 
mobile access gateway's IPv4 address (v4PCoA) as the visited 
address.  (The MAG address could also in theory be an IPv6 address (v6PCoa),

Or would PMIPv6 also manipulate the v6HoA entry, and if so, what would it do
- ? 

Anyway, the UE knows nothing about PMIPv6/IPv4-PMIPv6 and would 
like to send a BU de-registrating the v4HoA binding and refreshing the v6HoA
binding 
to use the v4HoA as IPv4 care-of-address. 
With the following desired result. 

This will result in two tunnels for IPv6 traffic from HA to UE, the outer
tunnel 
from HA to MAG (v4PCoa) and the inner IPv6 in IPv4 tunnel to v4HoA and as
both tunnels originates in the HA 
this will require two consecutive look ups in the binding cache for Ivy
traffic. But well, that's how thing goes. 

Example scenario 2: 

An UE boots up in the CC network, then moves to the AA network where host
mobility is 
not done using PMIP (instead it is done using GTP). As above we want to have
IPv6 
connectivity to the UE, because the PDN GW is connected to the 
IPv6 Internet as well as in order merely to use DSMIPv6 signaling, 
but we assume the AA and the CC network have IPv4 access 
connectivity only. 

The address allocation and binding procedures in the CC is as in Example 1. 
With resulting Binding cache entries. 

Second, the UE moves to the AA network, an IPv4-only network. 
Moving there, the mobile node is 
provided its IPv4 home address (v4HoA as above) as care-of-address. 
But without the involvement of PMIPv6 and the cache entries of the HA 
remains unaltered until the UE sends a DSMIPv6 BU. Again what the UE would
like 
is to send a BU deleting the v4HoA binding and refreshing the v6HoA binding 
to use the v4HoA as IPv4 care-of-address. 
With the following desired result. 

Again the issues is how this should be done. Proposed options are described
further below. 

Also please note that again, correctly manipulating the v6HoA binding cache
entry is required 
already alone to allow the HA to return the BACK. 

The UE could send a binding update with some non-zero lifetime, reporting
v6HoA 
to be found at v4HoA (in IPv4 care-of-address option), and additionally
including v4HoA (in home address option) 
The home agent should conclude that the equality of the two IPv4 addresses
means 
removal of the v4HoA cache entry. 
This does not imply changing any DSMIPv6 protocol messages, but it still
deserves some text to say how the HA 
should handle the situation when the v4HoA is the same as the CoA. 

Christian/Karen

---

From: "Tsirtsis, George" <[email-masked]>
Date: Wed, 17 Oct 2007 08:13:46 -0700

Karen,

I have been involved with the 3GPP Rel8 design (ex-SAE, currently called
EPS) for some time now and I have to say your e-mail confuses the hell
out of me. I will not go into all the statements I consider inaccurate
in your e-mail (too long!), but I will just point out the following:

There is nothing in EPS architecture that requires or implies that the
IPv4 and IPv6 home links need to be split. I do not know what gave you
that idea but it is just not true. Whether PMIPv6 or DSMIPv6 is used,
the corresponding LMA or HA, is supposed to be the owner of IPv4 and
IPv6 HoAs for a given MN (UE in 3GPP terms).

It is also not true that the MN (or UE) is never at its home link. 3GPP
accesses are typically expected to be configured as home links, in which
case PMIP/GTP connects the MN directly to the PDNGW (playing the role of
an LMA/HA). The address allocated to the MN via such accesses is then
meant to either be moved along with PMIPv6 or be treated as a DSMIPv6
HoA when the MN moves to other (non-3GPP) accesses.

So, as a summary, I personally have a lot of issues with the EPS
architecture but what you describe is not own of them.

BR

George

P.S.: BTW, I had to send this a second time after trimming the e-mail
because the mailing list bounces e-mail over 40K. I suggest Karen next
time publishes a draft :-)

________________________________

From: Hesham Soliman [mailto:[email-masked]] 
Sent: Wednesday, October 17, 2007 3:37 PM
To: [email-masked]; [email-masked];
[email-masked]
Subject: [Mip6] RE: DSMIP accommodation of split of v4 and v6 home link
?

Karen, Christian, 

Thanks for the write up. It's never boring with 3GPP's design choices
but unfortunately almost always sad....

Basically what you're describing is the result of making bad design
choices like allocating home addresses outside the home network and
effectively splitting the home network, while using every protocol under
the sun at the same time....sigh

Of course there are two ways of handling this: 1) This design breaks the
fundamental requirement of DSMIPv6, which is that the home link is
IPv6-enabled and therefore we don't need to address it or 2) allowing
this somehow, one way is obviously what you suggest. I'd like to hear
some more opionions on this. 

Hesham

________________________________

	From: [email-masked]
[mailto:[email-masked]] 
	Sent: Wednesday, October 10, 2007 5:52 PM
	To: [email-masked]; [email-masked];
[email-masked]
	Subject: DSMIP accommodation of split of v4 and v6 home link ?

	Hi Hesham, All 

	network gateway (PDN GW), and mobile access gateway
functionality 
	in the serving gateway (Serving GW), and mobile node
functionality 
	in the UE.  The UE can be attached to the 3GPP in the following
ways. 

	      terminated in the PDN GW and the PDN GW hosts
corresponding 

	 * UE can have non-3GPP access with network-based mobility.  In 
	   this instance the mobile access gateway functionality is 
	   hosted in either the access gateway of the non-3GPP access
network 
	   or in the evolved packet data gateway (ePDG), while the
corresponding local 
	   mobility anchor functionality is hosted in the PDN GW.  
	   This network is denoted the BB network. 

	 * UE can have non-3GPP access with host-based mobility, in
which 
	   case the mobile node uses DSMIP while the PDN GW hosts the 
	   corresponding home agent functionality.  This network is 
	   denoted the CC network. 

	From a IP mobility perspective there is not much difference in
between AA and BB. 
	The notably difference in between the networks are 
	* the possible usage of GTP in AA 
	* potential difference in IPv6 and IPv4 access support 

	In both networks, then from a IP mobility perspective, all user
layer IP access addresses provided to 
	the UE are home addresses and the address allocation is
administratively controlled by the 
	PDN GW which will ensure that the access addresses given out are
the same on the two networks. 

	As addresses are carried over in between the AA and all BB
networks, the UE 
	IPv6 home link spreads over potentially multiple BB networks and
one AA network. 
	Likewise for the IPv4 Home link. 

	The peculiar situation that we would like to support is the
situation, 
	presumably primarily a transition period, where the AA network 
	or the BB network (or both) does not support IPv6 access
addresses. 

	But where still: 
	* the UE uses an IPv6 HoA for DSMIPv6 signaling (obviously, this
is a MUST) 
	* the UE may roam in between AA and BB using an IPv4 HoA 
	* the UE may use DSMIPv6 to roam in and out of CC 
	* the UE may use DSMIPv6 to roam in between the AA network and
BB networks with different 
	IP access (plus/minus IPv6) capabilities. 

	If neither of the networks (AA and BB) supports IPv6 access,
then 
	the UE will never be at home IPv6 wise. 

	Conceptually the AA and the BB networks run network based
mobility on IPv4 access 
	but when IPv6 access cannot be provided, then 
	the idea is to use DSMIPv6 in parallel to manage IPv6 mobility. 

	This represents a logical split of the IPv4 and the IPv6 home
link. 

	an IPv4 PDP context in the 3GPP access (AA network).  Another
motivation is 

	Based on this overall scenario description, and looking into
DSMIP and its interaction with 
	PMIPv6 and IPv4-PMIPv6, the functionality which we are after and

	which we cannot find explicitly described anywhere, is to allow
DSMIPv6 to operate more 
	independently on the v6HoA and v4HoA cache entries. Specifically
so 
	that a UE may use DSMIPv6 to signal 
	* deregistration of an v4HoA registration 
	* registration(update) of v6HoA DSMIPv6 registration to
care-of-address equal v4Hoa 
	in one and the same DSMIPv6 BU.

---

From: <[email-masked]>
Date: Fri, 19 Oct 2007 11:51:09 +0200

Hi George,
 
Thanks a lot for your response.
 
I will say, very briefly, what is our point.
I do not what to pollute the mailing list with too 
much misguided 3GPP non-sense 
if that is what this is (from my side, that is !).
 
I agree with everything you say about address allocations 
and how addresses moves along with the MN
when it moves to other non-3GPP accesses (controlled by (IPv4-)PMIPv6 or
DSMIPv6 respectively) 
 
The term "split of v4 and v6 home link" used by me, should be understood

NOT TO SAY that the v4 and v6 home link is administratively split in
between different operators, APN's or anything like that.
INSTEAD the intention is to split away the tight coupling in between the
v4 and the v6 home link which is present today in DSMIPv6
THEREBY ACCOMMODATING pre-LTE/SAE (or ESP) architectures where  the HOME
or VISITED 3GPP operator does not support 
IPv6 PDP contexts.
 
In this situation, then alone to support v4 handovers, the MN needs a v6
HoA for DSMIPv6 signaling. 
In addition, then it would not hurt, if the MN could also use this v6
address for v6 connectivity via a reverse DSMIPv6 tunnel to its HA.
 
What we describe is this situation and what we propose is a way to
handle this situation using DSMIPv6.
 
I know that there are unclear point in the currents 3GPP specs, some (it
seems) due to the write-up being a mixture of what
could be achieved with 4285bis-like "DSMIPv6" operation and some which
can be achieved with IKEv2, IPSec and DSMIPv6.
In this context then the details we give is in the DSMIPv6 and IKEv2
solution realm, but I would like to stress that the issue 
as well as the solution is, on a high-level, not dependent on whether we
are speaking IKEv2 or 4285bis-like based authentication.
 
If DSMIPv6 closes now, then I suppose that we will have to write this up
in a draft - :-)
 
BR, Karen

	From: Tsirtsis, George [mailto:[email-masked]] 
	Sent: Wednesday, October 17, 2007 5:14 PM
	To: Hesham Soliman; Nielsen Karen E; [email-masked];
Kaas-Petersen Christian
	Subject: RE: [Mip6] RE: DSMIP accommodation of split of v4 and
v6 home link ?

	Karen,

	I have been involved with the 3GPP Rel8 design (ex-SAE,
currently called EPS) for some time now and I have to say your e-mail
confuses the hell out of me. I will not go into all the statements I
consider inaccurate in your e-mail (too long!), but I will just point
out the following:

	There is nothing in EPS architecture that requires or implies
that the IPv4 and IPv6 home links need to be split. I do not know what
gave you that idea but it is just not true. Whether PMIPv6 or DSMIPv6 is
used, the corresponding LMA or HA, is supposed to be the owner of IPv4
and IPv6 HoAs for a given MN (UE in 3GPP terms).

	It is also not true that the MN (or UE) is never at its home
link. 3GPP accesses are typically expected to be configured as home
links, in which case PMIP/GTP connects the MN directly to the PDNGW
(playing the role of an LMA/HA). The address allocated to the MN via
such accesses is then meant to either be moved along with PMIPv6 or be
treated as a DSMIPv6 HoA when the MN moves to other (non-3GPP) accesses.

	BR

	George

	P.S.: BTW, I had to send this a second time after trimming the
e-mail because the mailing list bounces e-mail over 40K. I suggest Karen
next time publishes a draft :-)

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Oct 2007 12:26:24 +0200

GEorge, Karen, I support the initiative to have DS-MIPv6 support split 
IPv4-IPv6 home networks.

I think it is reasonable to assume that an operator runs an 
IPv6-exclusive home network whose mobiles attach to a IPv4-exclusive 
Access Network.

Alex

[email-masked] wrote:
>     ------------------------------------------------------------------------
>     *From:* Tsirtsis, George [mailto:[email-masked]]
>     *Sent:* Wednesday, October 17, 2007 5:14 PM
>     *To:* Hesham Soliman; Nielsen Karen E; [email-masked]; Kaas-Petersen
>     Christian
>     *Subject:* RE: [Mip6] RE: DSMIP accommodation of split of v4 and v6
>     home link ?
> 
>     Karen,
> 
>      
> 
>     I have been involved with the 3GPP Rel8 design (ex-SAE, currently
>     called EPS) for some time now and I have to say your e-mail confuses
>     the hell out of me. I will not go into all the statements I consider
>     inaccurate in your e-mail (too long!), but I will just point out the
>     following:
> 
>      
> 
>     There is nothing in EPS architecture that requires or implies that
>     the IPv4 and IPv6 home links need to be split. I do not know what
>     gave you that idea but it is just not true. Whether PMIPv6 or
>     DSMIPv6 is used, the corresponding LMA or HA, is supposed to be the
>     owner of IPv4 and IPv6 HoAs for a given MN (UE in 3GPP terms).
> 
>      
> 
>     It is also not true that the MN (or UE) is never at its home link.
>     3GPP accesses are typically expected to be configured as home links,
>     in which case PMIP/GTP connects the MN directly to the PDNGW
>     such accesses is then meant to either be moved along with PMIPv6 or
>     be treated as a DSMIPv6 HoA when the MN moves to other (non-3GPP)
>     accesses.
> 
>      
> 
>     e-mail because the mailing list bounces e-mail over 40K. I suggest
>     Karen next time publishes a draft :-)
> 
>      
> 
>     ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 19 Oct 2007 20:28:57 +1000

> IPv6-exclusive home network whose mobiles attach to a IPv4-exclusive 

=> This is NOT what Karen is talking about. She's talking about an IPv4-only
home network that offers IPv6 service....

Hesham

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Oct 2007 12:32:48 +0200

> home network that offers IPv6 service....

I don't get it... but I prefer to give it up :-)

Alex

---

From: <[email-masked]>
Date: Fri, 19 Oct 2007 13:03:24 +0200

> home network that offers IPv6 service....

Correct - and even more so:

An Ipv4 only home network where handovers to v4 and/or v6 networks
are controlled using DSMIPv6. 

So the "Ipv6 service" is required alone for mobility support, 
but can be used as well for IPv6 connectivity.

The Ipv6 service (v6HoA) is provided NOT FROM the attach to the access
network 
BUT FROM the DSMIPv6 HA.

With current DSMIPv6 this can be achieved, but then the MN will
not be at home in the v4-only home network (because it is not at home v6
wise)
and the consequence is that in order to have an v4 address that survives
movements, the MN
would have to acquire also an v4HoA from the HA 
and all v4 communications would have to be ip-in-ip tunneled also over
the v4-only home network.

We would like to remove this extra tunnel.

Why use DSMIPv6 at all for these scenarios - why not use some flavor of
Mipv4 ? Because 
DSMIPv6 it is the chosen future proof solution which
will work also when the operator provides "direct ipv6 access" service.

Karen

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 19 Oct 2007 11:13:41 -0700

Karen,

> address for v6 connectivity via a reverse DSMIPv6 tunnel to its HA.

The access network can be be IPv4-only. The mobile node does need an
IPv6 Home Address all the time.

If you are making a particular access link a home link, then the
access network should understand IPv6. It can't be IPv4-only.

Vijay

> as well as the solution is, on a high-level, n ot dependent on whether 
> we are speaking IKEv2 or 4285bis-like based authentication.
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 19 Oct 2007 11:17:00 -0700

> are controlled using DSMIPv6. 

You cannot deploy DS-MIPv6 in an IPv4-only home network. I don't
believe the on-going work in 3GPP is trying to do this.

Vijay